swift ?和!之间区别:
Swift 引入的最不一样的可能就是 Optional Value 了。在声明时,我们可以通过在类型后面加一个?
来将变量声明为 Optional 的。如果不是 Optional 的变量,那么它就必须有值。而如果没有值的话,我们使用 Optional 并且将它设置为 nil
来表示没有值。
//num 不是一个 Int var num: Int? //num 没有值 num = nil //nil //num 有值 num = 3 //{Some 3}
Apple 在 Session 上告诉我们,Optinal Value 其实就是一个盒子,你盒子里可能装着实际的值,也可能什么都没装。
我们看到 Session 里或者文档里天天说 Optional Optional,但是我们在代码里基本一个 Optional 都没有看到,这是为什么呢?而且,上面代码中给 num
赋值为 3 的时候的那个输出为什么看起来有点奇怪?其实,在声明类型时的这个 ?
仅仅只是 Apple 为了简化写法而提供的一个语法糖。实际上我们是有 Optional 类型的声明,就这里的 num
为例,最正规的写法应该是这样的:
//真 Optional 声明和使用 var num: Optional<Int> num = Optional<Int>() num = Optional<Int>(3)
没错,num
不是 Int
类型,它是一个 Optional
类型。到底什么是 Optional
呢,点进去看看:
enum Optional<T> : LogicValue, Reflectable { case None case Some(T) init() init(_ some: T) /// Allow use in a Boolean context. func getLogicValue() -> Bool /// Haskell's fmap, which was mis-named func map<U>(f: (T) -> U) -> U? func getMirror() -> Mirror }
你也许会大吃一惊。我们每天和 Swift 打交道用的 Optional 居然是一个泛型枚举 enum
,而其实我们在使用这个枚举时,如果没有值,我们就规定这个枚举的是 .None
,如果有,那么它就是Some(value)
(带值枚举这里不展开了,有不明白的话请看文档吧)。而这个枚举又恰好实现了LogicValue
接口,这也就是为什么我们能使用 if
来对一个 Optinal 的值进行判断并进一步进行 unwrap 的依据。
var num: Optional<Int> = 3 if num { //因为有 LogicValue, //.None 时 getLogicValue() 返回 false //.Some 时返回 true var realInt = num! realInt //3 }
既然 var num: Int? = nil
其实给 num
赋的值是一个枚举的话,那这个 nil
到底又是什么?它被赋值到哪里去了?一直注意的是,Swift 里的 nil 和 objc 里的 nil 完全不是一回事儿。objc 的 nil 是一个实实在在的指针,它指向一个空的对象。而这里的 nil 虽然代表空,但它只是一个语意上的概念,确是有实际的类型的,看看 Swift 的 nil
到底是什么吧:
/// A null sentinel value. var nil: NilType { get }
nil
其实只是 NilType
的一个变量,而且这个变量是一个 getter。Swift 给了我们一个文档注释,告诉我们 nil
其实只是一个 null 的标记值。实际上我们在声明或者赋值一个 Optional 的变量时,?
语法糖做的事情就是声明一个 Optional<T>
,然后查看等号右边是不是 nil 这个标记值。如果不是,则使用init(_ some: T)
用等号右边的类型 T 的值生成一个 .Some
枚举并赋值给这个 Optional 变量;如果是 nil,将其赋为 None 枚举。
所以说,Optional背后的故事,其实被这个小小的 ?
隐藏了。
我想,Optional 讨论到这里就差不多了,还有三个小问题需要说明。
首先,NilType
这个类型非常特殊,它似乎是个 built in 的类型,我现在没有拿到关于它的任何资料。我本身逆向是个小白,现在看起来 Swift 的逆向难度也比较大,所以关于 NilType
的一些行为还是只能猜测。而关于 nil
这一 NilType
的类型的变量来说,猜测的话,它可能是 Optional.None
的一种类似多型表现,因为首先它确实是指向 0x0 的,并且与 Optional.None 的 content 的内容指向一致。但是具体细节还要等待挖掘或者公布了。
其次,Apple 推荐我们在 unwrap 的时候使用一种所谓的隐式方法,即下面这种方式来 unwrap:
var num: Int? = 3 if let n = num { //have a num } else { //no num }
最后,这样隐式调用足够安全,性能上似乎应该也做优化(有点忘了..似乎说过),推荐在 unwrap 的时候尽可能写这样的推断,而减少直接进行 unwrap 这种行为。
最后一个问题是 Optional 的变量也可以是 Optinal。因为 Optional 就相当于一个黑盒子,可以知道盒子里有没有东西 (通过 LogicValue),也可以打开这个盒子 (unwrap) 来拿到里面的东西 (你要的类型的变量或者代表没有东西的 nil)。请注意,这里没有任何规则限制一个 Optional 的量不能再次被 Optional,比如下面这种情况是完全 OK 的:
var str: String? = "Hi" //{Some "Hi"} var anotherStr: String?? = str //{{Some "Hi"}}
这其实是没有多少疑问的,很完美的两层 Optional,使用的时候也一层层解开就好。但是如果是 nil 的话,在这里就有点尴尬...
var str: String? = nil
var anotherStr: String?? = nil
? 那是什么??,! 原来如此!!
问号和叹号现在的用法都是原来 objc 中没有的概念。说起来简单也简单,但是背后也还是不少玄机。原来就已经存在的用法就不说了,这里把新用法从浅入深逐个总结一下吧。
首先是 ?
:
?
放在类型后面作为 Optional 类型的标记
这个用法上面已经说过,其实就是一个 Optional<T>
的语法糖,自动将等号后面的内容 wrap 成 Optional。给个用例,不再多说:
var num: Int? = nil //声明一个 Int 的 Optional,并将其设为啥都没有 var str: String? = "Hello" //声明一个 String 的 Optional,并给它一个字符串
?
放在某个 Optional 变量后面,表示对这个变量进行判断,并且隐式地 unwrap。比如说
foo?.somemethod()
相比起一般的先判断再调用,类似这样的判断的好处是一旦判断为 nil
或者说是 false
,语句便不再继续执行,而是直接返回一个 nil。上面的写法等价于
if let maybeFoo = foo { maybeFoo.somemethod() }
这种写法更存在价值的地方在于可以链式调用,也就是所谓的 Optional Chaining,这样可以避免一大堆的条件分支,而使代码变得易读简洁。比如:
if let upper = john.residence?.address?.buildingIdentifier()?.uppercaseString { println("John's uppercase building identifier is (upper).") }
注意最后 buildingIdentifier
后面的问号是在 ()
之后的,这代表了这个 Optional 的判断对象是buildingIdentifier()
的返回值。
?
放在某个 optional 的 protocol 方法的括号前面,以表示询问是否可以对该方法调用
这中用法相当于以前 objc 中的 -respondsToSelector:
的判断,如果对象响应这个方法的话,则进行调用。例子:
delegate?.questionViewControllerDidGetResult?(self, result)
中的第二个问号。注意和上面在 ()
后的问号不一样,这里是在 ()
之前的,表示对方法的询问。
其实在 Swift 中,默认的 potocol 类型是没有 optional 的方法的,因为基于这个前提,可以对类型安全进行确保。但是 Cocoa 框架中的 protocol 还是有很多 optional 的方法,对于这些可选的接口方法,或者你想要声明一个带有可选方法的接口时,必须要在声明 protocol
时再其前面加上 @objc
关键字,并在可选方法前面加上 @optional
:
@objc protocol CounterDataSource { @optional func optionalMethod() -> Int func requiredMethod() -> Int @optional var optionalGetter: Int { get } }
然后是 !
新用法的总结
!
放在 Optional 变量的后面,表示强制的 unwrap 转换:
foo!.somemethod()
这将会使一个 Optional<T>
的量被转换为 T
。但是需要特别注意,如果这个 Optional 的量是 nil 的话,这种转换会在运行时让程序崩溃。所以在直接写 !
转换的时候一定要非常注意,只有在有必死决心和十足把握时才做 !
强转。如果待转换量有可能是 nil 的话,我们最好使用 if let
的语法来做一个判断和隐式转换,保证安全。
!
放在类型后面,表示强制的隐式转换。
这种情况下和 ?
放在类型后面的行为比较类似,都是一个类型声明的语法糖。?
声明的是 Optional
,而 !
其实声明的是一个 ImplicitlyUnwrappedOptional
类型。首先需要明确的是,这个类型是一个struct
,其中关键部分是一个 Optional<T>
的 value,和一组从这个 value 里取值的 getter 和 方法:
struct ImplicitlyUnwrappedOptional<T> : LogicValue, Reflectable { var value: T? //... static var None: T! { get } static func Some(value: T) -> T! //... }
从外界来看,其实这和 Optional
的变量是类似的,有 Some
有 None
。其实从本质上来说,ImplicitlyUnwrappedOptional
就是一个存储了 Optional
,实现了 Optional
对外的方法特性的一个类型,唯一不同的是,Optional
需要我们手动进行进行 unwrap (不管是使用 var!
还是 let if
赋值,总要我们做点什么),而 ImplicitlyUnwrappedOptional
则会在使用的时候自动地去 unwrap,并对继续之后的操作调用,而不必去增加一次手动的显示/隐式操作。
为什么要这么设计呢?主要是基于 objc 的 Cocoa 框架的两点考虑和妥协。
首先是 objc 中是有指向空对象的指针的,就是我们所习惯的 nil
。在 Swift 中,为了处理和 objc 的 nil 的兼容,我们需要一个可为空的量。而因为 Swift 的目的就是打造一个完全类型安全的语言,因此不仅对于 class,对于其他的类型结构我们也需要类型安全。于是很自然地,我们可以使用 Optional 的空来对 objc 做等效。因为 Cocoa 框架有大量的 API 都会返回 nil,因此我们在用 Swift 表达它们的时候,也需要换成对应的既可以表示存在,也可以表示不存在的 Optional
。
那这样的话,不是直接用 Optional
就好了么?为什么要弄出一个 ImplicitlyUnwrappedOptional
呢?因为易用性。如果全部用 Optional
包装的话,在调用很多 API 时我们就都需要转来转去,十分麻烦。而对于 ImplicitlyUnwrappedOptional
因为编译器为我们进行了很多处理,使得我们在确信返回值或者要传递的值不是空的时候,可以很方便的不需要做任何转换,直接使用。但是对于那些 Cocoa 有可能返回 nil,我们本来就需要检查的方法,我们还是应该写 if 来进行转换和检查。
比如说,以下的写法就会在运行时导致一个 EXC_BAD_INSTRUCTION
let formatter = NSDateFormatter() let now = formatter.dateFromString("not_valid") let soon = now.dateByAddingTimeInterval(5.0) // EXC_BAD_INSTRUCTION
因为 dateFromString
返回的是一个 NSDate!
,而我们的输入在原来会导致一个 nil
的返回,这里我们在使用 now 之前需要进行检查:
let formatter = NSDateFormatter() let now = formatter.dateFromString("not_valid") if let realNow = now { realNow.dateByAddingTimeInterval(5.0) } else { println("Bad Date") }
这和以前在 objc 时代做的事情差不多,或者,用更 Swift 的方式做
let formatter = NSDateFormatter() let now = formatter.dateFromString("not_valid") let soon = now?.dateByAddingTimeInterval(5.0)