Objective-C中nullable翠霍、__nullable锭吨、_Nullable、_Nonnull的用法

在?Swift?中寒匙，我們會使用???和?!?去顯式聲明一個對象或者方法的參數(shù)是optional?還是?non-optional?零如，而在?Objective-C?中則沒有這一區(qū)分，這樣就會帶來一個問題：在?Swift?與Objective-C?混編時锄弱，Swift?編譯器并不知道一個?Objective-C?對象或者一個方法的參數(shù)到底是?optional?還是?non-optional?考蕾，因此這種情況下編譯器會隱式地都當(dāng)成是?non-optional?來處理，這顯然是不太好的会宪。

挖坑

為了解決這個問題肖卧，蘋果在?Xcode 6.3?引入了一個?Objective-C?的新特性：?Nullability Annotations?，這一新特性的核心是兩個新的類型修飾：?__nullable?和?__nonnull?掸鹅。從字面上我們可知塞帐，?__nullable?表示對象可以是?NULL?或?nil，而__nonnull?表示對象不應(yīng)該為空巍沙。當(dāng)我們不遵循這一規(guī)則時葵姥，編譯器就會給出警告。在?Xcode 7?中赎瞎，為了避免與第三方庫潛在的沖突牌里，蘋果把?__nonnull/__nullable改成?_Nonnull/_Nullable?颊咬。再加上蘋果同樣支持了沒有下劃線的寫法?nonnull/nullable?务甥，于是就造成現(xiàn)在有三種寫法這樣混亂的局面牡辽。但是這三種寫法本質(zhì)上都是互通的，只是放的位置不同敞临，舉例如下：

? ??而對于雙指針類型對象?态辛、?Block 的返回值?、?Block 的參數(shù)?等挺尿，這時候就不能用?nonnull/nullable?修飾奏黑，只能用帶下劃線的?__nonnull/__nullable?或者?_Nonnull/_Nullable?：

以上基本上羅列了絕大部分的使用場景，但看完我們還是一臉懵逼啊编矾，仍然不清楚什么時候應(yīng)該用哪個修飾符熟史！

總結(jié)如下：

在看了原生 iOS SDK 里 Foundation 和 UIKit 的頭文件以及蘋果的博文?《Nullability and Objective-C》?，我們總結(jié)如下使用規(guī)范：

對于屬性窄俏、方法返回值蹂匹、方法參數(shù)的修飾，使用：nonnull/nullable凹蜈；

對于 C 函數(shù)的參數(shù)限寞、Block 的參數(shù)、Block 返回值的修飾仰坦，使用：_Nonnull/_Nullable履植，建議棄用__nonnull/__nullable。

Nonnull Audited Regions

如果需要每個屬性或每個方法都去指定?nonnull?和?nullable?悄晃，將是一件非常繁瑣的事玫霎。蘋果為了減輕我們的工作量，專門提供了兩個宏：?NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END妈橄。在這兩個宏之間的代碼鼠渺，所有簡單指針對象都被假定為nonnull，因此我們只需要去指定那些nullable指針對象即可眷细。如下代碼所示：

在上面的代碼中拦盹，aString屬性默認(rèn)是nonnull的，methodWithString:方法的返回值也是nonnull溪椎，而方法的參數(shù)str被顯式指定為nullable普舆。

不過，為了安全起見校读，蘋果還制定了以下幾條規(guī)則：

通過typedef定義的類型的nullability特性通常依賴于上下文沼侣，即使是在 Audited Regions 中，也不能假定它為nonnull歉秫；

對于復(fù)雜的指針類型（如id *）必須顯式去指定是nonnull還是nullable蛾洛。例如，指定一個指向nullable對象的nonnull指針，可以使用__nullable id * __nonnull轧膘；

我們經(jīng)常使用的NSError **通常是被假定為一個指向nullableNSError 對象的nullable指針钞螟。

轉(zhuǎn)自：http://www.tuicool.com/articles/ZBnEveU