轉(zhuǎn)自 http://blog.sina.com.cn/s/blog_5c91824f0102vxpd.html 我自己當筆記記錄存哲，學習請看原博客。
最近在用Xcode 6.3寫代碼柄冲，一些涉及到對象的代碼會報如下編譯器警告：
Pointer is missing a nullability type specifier (__nonnullor__nullable)
于是google了一下，發(fā)現(xiàn)這是Xcode 6.3的一個新特性，即nullability annotations哄尔。
Nullability Annotations
我們都知道在swift中崖堤，可以使用!和?來表示一個對象是optional的還是non-optional侍咱，如view?和view!。而在Objective-C中則沒有這一區(qū)分密幔，view即可表示這個對象是optional楔脯，也可表示是non-optioanl。這樣就會造成一個問題：在Swift與Objective-C混編時胯甩，Swift編譯器并不知道一個Objective-C對象到底是optional還是non-optional昧廷，因此這種情況下編譯器會隱式地將Objective-C的對象當成是non-optional。
為了解決這個問題偎箫，蘋果在Xcode 6.3引入了一個Objective-C的新特性：nullability annotations木柬。這一新特性的核心是兩個新的類型注釋：__nullable和__nonnull。從字面上我們可以猜到镜廉，__nullable表示對象可以是NULL或nil弄诲，而__nonnull表示對象不應該為空。當我們不遵循這一規(guī)則時娇唯，編譯器就會給出警告齐遵。
我們來看看以下的實例，
@interfaceTestNullabilityClass()
@property(nonatomic,copy)NSArray*items;
-(id)itemWithName:(NSString*__nonnull)name;
@end
@implementationTestNullabilityClass
...
-(void)testNullability{
? ? [selfitemWithName:nil];//編譯器警告：Nullpassedtoacalleethatrequiresanon-nullargument
}
-(id)itemWithName:(NSString*__nonnull)name{
? ? ?returnnil;
}
@end
不過這只是一個警告塔插，程序還是能編譯通過并運行梗摇。
事實上，在任何可以使用const關鍵字的地方都可以使用__nullable和__nonnull想许，不過這兩個關鍵字僅限于使用在指針類型上伶授。而在方法的聲明中断序，我們還可以使用不帶下劃線的nullable和nonnull，如下所示：
-(nullableid)itemWithName:(NSString*nonnull)name
在屬性聲明中糜烹，也增加了兩個相應的特性违诗，因此上例中的items屬性可以如下聲明：
@property(nonatomic,copy,nonnull)NSArray*items;
當然也可以用以下這種方式：
@property(nonatomic,copy)NSArray*__nonnullitems;
推薦使用nonnull這種方式，這樣可以讓屬性聲明看起來更清晰疮蹦。
Nonnull區(qū)域設置(Audited Regions)
如果需要每個屬性或每個方法都去指定nonnull和nullable诸迟，是一件非常繁瑣的事。蘋果為了減輕我們的工作量愕乎，專門提供了兩個宏：NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END阵苇。在這兩個宏之間的代碼，所有簡單指針對象都被假定為nonnull感论，因此我們只需要去指定那些nullable的指針绅项。如下代碼所示：
NS_ASSUME_NONNULL_BEGIN
@interfaceTestNullabilityClass()
@property(nonatomic,copy)NSArray*items;
-(id)itemWithName:(nullableNSString*)name;
@end
NS_ASSUME_NONNULL_END
在上面的代碼中，items屬性默認是nonnull的比肄，itemWithName:方法的返回值也是nonnull快耿，而參數(shù)是指定為nullable的。
不過芳绩，為了安全起見润努，蘋果還制定了幾條規(guī)則：
typedef定義的類型的nullability特性通常依賴于上下文，即使是在Audited Regions中示括，也不能假定它為nonnull铺浇。
復雜的指針類型(如id *)必須顯示去指定是nonnull還是nullable。例如垛膝，指定一個指向nullable對象的nonnull指針鳍侣，可以使用”__nullable id * __nonnull”。
我們經(jīng)常使用的NSError **通常是被假定為一個指向nullable NSError對象的nullable指針吼拥。
兼容性
因為Nullability Annotations是Xcode 6.3新加入的倚聚，所以我們需要考慮之前的老代碼。實際上凿可，蘋果已以幫我們處理好了這種兼容問題惑折，我們可以安全地使用它們：
老代碼仍然能正常工作，即使對nonnull對象使用了nil也沒有問題枯跑。
老代碼在需要和swift混編時惨驶，在新的swift編譯器下會給出一個警告。
nonnull不會影響性能敛助。事實上粗卜，我們?nèi)匀豢梢栽谶\行時去判斷我們的對象是否為nil。
事實上纳击，我們可以將nonnull/nullable與我們的斷言和異常一起看待续扔，其需要處理的問題都是同一個：違反約定是一個程序員的錯誤攻臀。特別是，返回值是我們可控的東西纱昧，如果返回值是nonnull的刨啸，則我們不應該返回nil，除非是為了向后兼容识脆。
