Nullability 和 Objective-C
英文原文链接
Swift 的一大优点是它能与 Objective-C 代码混编，不论是由 Objective-C 写成的库还是你的应用中的 Objective-C 代码都可以畅通的与 Swift 交互。然而，在 Swift 里可选（optional）的引用与非可选（non-optional）的引用泾渭分明，例如NSView VS. NSView?，在 Objective-C 里这两种类型都对应NSView *。因为 Swift 的编译器判断不出某个NSView *是否是可选值，因此转换为 Swift 的类型就是隐式解包可选类型NSView!。
在之前版本的 Xcode 中，有些苹果官方的框架经过了专门的审核，来让 API 正确反映在 Swift 中是否是可选类型。为了支持在你自己的代码里也能实现这种功能，Xcode 6.3 推出了一项新的 Objective-C 语言特性：nullability annotations 。
核心：nullable 与 nonnull
这项新特性的核心是两个新的类型注解：__nullable与__nonnull。正如你所想，标记了__nullable的指针的值有可能为NULL或nil，而__nonnull的指针则不可能。如果违反这些规则，编译器会发出警告。
@interface AAPLList : NSObject <NSCoding,NSCopying> // ... - (AAPLListItem * __nullable)itemWithName:(NSString * __nonnull)name; @property (copy, readonly) NSArray * __nonnull allItems; // ... @end // -------------- [self.list itemWithName:nil]; // warning!
几乎所有能用 C 传统的const关键字的地方都能用__nullable和__nonnull，当然只能用在指针类型上。不过，一般情况下有一个更好的方法来使用这两个注解：用在方法声明里时可以不用加下划线，直接写在左括号后面，只需后面的类型是普通对象或 block 的指针。
- (nullable AAPLListItem *)itemWithName:(nonnull NSString *)name; - (NSInteger)indexOfItem:(nonnull AAPLListItem *)item;
对于属性，也可以不用加下划线，写在属性特性列表里即可。
- (nullable AAPLListItem *)itemWithName:(nonnull NSString *)name; - (NSInteger)indexOfItem:(nonnull AAPLListItem *)item;
不加下划线的形式比加下划线的要好一些，不过你仍然需要在头文件的每个类型前都加一遍注解。想要轻松一些同时让头文件更简洁，你可以使用审核区(audited region)。
审核区
为了循序渐进地采用这些新注解，你可以给 Objective-C 头文件中的一个区块加上“经过非空审核”的标记。在这个区块内部，每个普通的指针类型都会默认为非空。这能让上文的例子大大简化：
<span style="color:#ff0000;">NS_ASSUME_NONNULL_BEGIN</span><span style="color:#3e3e3e;"> @interface AAPLList : NSObject <NSCoding, NSCopying> // ... - (nullable AAPLListItem *)itemWithName:(NSString *)name; - (NSInteger)indexOfItem:(AAPLListItem *)item;// 没有标记 @property (copy, nullable) NSString *name; @property (copy, readonly) NSArray *allItems; // ... @end </span><span style="color:#ff0000;">NS_ASSUME_NONNULL_END</span><span style="color:#3e3e3e;"> // -------------- self.list.name = nil; // okay AAPLListItem *matchingItem = [self.list itemWithName:nil]; // warning!</span>
出于安全考虑，这条规则有几个例外：
-
typedef 类型一般没有内在的可空性——它们要么为空，要么非空，根据具体的取值而定。因此，即使在审核区内，typedef 类型也不会默认为nonnull。
-
复合指针类型，如id *，必须显式使用注解。例如，指明一个非空的指针指向可空的对象引用，要用__nullable id * __nonnull。
-
一个比较特殊的类型NSError **一般用来在方法参数中返回错误信息，因此它总是默认为可空的指针指向可空的NSError引用。
这方面的更多信息可以参考Error Handling Programming Guide。
兼容性
如果现有的代码用到了你的 Objective-C 框架，却与你指定的非空性规则相互抵触怎么办？就这样一下子改变你的类型真的安全吗？放心，是安全的。
-
现有的编译好的代码如果用到了你的框架，仍然能正常运行，也就是说 ABI 不会变。这也意味着这些现有的代码在运行时不会捕捉到传递 nil 的错误。
-
现有的源代码如果用到了你的框架，用新的 Swift 编译器编译时，会得到不安全用法的警告。
-
nonnull 不会影响编译优化。尤其是，你仍然可以在运行时检查标注为nonnull的参数，看它实际上是不是nil。这对于向前兼容可能是必要的。
总体来说，基本上你应该像看待 assertion 或 exception 一样看待nullable与nonnull：违反这些规则是程序员的错误。尤其是，返回值是你能控制的，所以一定不要对非空的返回类型返回nil，除非是为了向前兼容。
回到 Swift
现在我们已经给 Objective-C 的头文件加了可空性注解，来看看在 Swift 里该怎么用吧：(这个地方有问题，英文原文也如此)
在给 Objective-C 代码加注解之前：
class AAPLList : NSObject, NSCoding, NSCopying {
// ...
func itemWithName(name: String!) -> AAPLListItem!
func indexOfItem(item: AAPLListItem!) -> Int
@NSCopying var name: String! { get set }
@NSCopying var allItems: [AnyObject]! { get }
// ...
}
加了注解之后：
class AAPLList : NSObject, NSCoding, NSCopying {
// ...
func itemWithName(name: String) -> AAPLListItem?
func indexOfItem(item: AAPLListItem) -> Int
@NSCopying var name: String? { get set }
@NSCopying var allItems: [AnyObject] { get }
// ...
}
Swift 的代码更清晰了。只是一个微小的改变，却能让你的框架更易于使用。
C 和 Objective-C 的可空性注解在 Xcode 6.3 及以后版本可用。查看更多信息，请参考Xcode 6.3 Release Notes。