強制解包看 Swift 的設計

不知道大家有沒有發現，在一個 Objective-C 和 Swift 混編的 App 中，當把一個 OC 中的參數轉到 Swift 時，Swift 會自動把這個變數進行強制解包。舉個例子，我在 OC 中定義這樣一個變數：

@property (nonatomic, copy) NSString *foo;

它轉成 Swift 就變成了這樣：

var foo: String!

這樣看上去合情合理。Swift 中有 String? 和 String! 兩種形式，但 OC 中沒有 NSString? 和 NSString! ，當 Swift 無法區分 OC 中的變數是不是 nil 的時候，一律強行轉化為非空參數。這樣設計體現了 Swift 強安全性語言的特性。

但是這時候問題來了。我們回到上文中的例子，假如 OC 中對 foo的使用如下：

@property (nonatomic, copy) NSString *foo;

- (void)secretFunc {  
  // 一些詭異複雜的操作
  ...  
  self.foo = nil;
}

然後我們在 Swift 中這樣調用：

func init() {
  objectiveCObject.secretFunc()

}func calcLen() -> Int {  

  return objectiveCObject.foo.characters.count

}

上面這段 Swift 代碼執行到calcLen()時會崩潰，原因是foo在init()中已經被設成了 nil，而foo在 Swift 中是 foo!。也就是說，因為 Swift 對 OC 變數的強轉，導致了程式的崩潰。這是一個很容易忽略的問題，因為強轉的時候，Xcode 不會給出任何的警告、報錯或是提醒。而我們作為開發者，很容易忽略這樣的錯誤，導致 runtime 的時候直接崩潰。

針對這種情況，我們來討論下麵三個問題。

• Q: 為什麼 Swift 要將 OC 中的變數如foo轉為foo!而不是foo?

這是一個有爭議的話題。我個人認為強制解包的方式會督促開發者考慮變數是否為 nil 的問題。在 OC 時代，聲明變數一般不會考慮是否為空的問題；而在 Swift 時代，因為其是一門強安全性的語言，在變數定義時，必須確定變數是否為空。一般定義為非空有兩種以下形式：

// force unwrapping
var foo = "Hello"
// implicitly unwrapping
var foo: String!

前者根據初始值強制解包，定義 foo 為非空變數；後者則直接申明 foo 為非空變數。

無論哪種情況，開發者會從一開始就思考處理 nil 時的情況，併在後續開發中一直註意。所以從foo轉化為foo!，你就會思考 OC 中代碼是否也要處理
nil 的情況；而如果轉化為foo?，nil 也無所謂，而實際可能並不是這樣，nil 的特殊情況考慮會一直忽略，開發中的隱患一直存在，同時也不符合 Swift 強安全性的設計思路。

• Q: 我就想讓 OC 中的變數從foo轉化到 Swift 中變成foo?，有沒有辦法

請這樣在 OC 中定義變數：

// foo -> foo?
@property (nullable, nonatomic, copy) NSString *foo;
// bar -> bar!
@property (nonnull, nonatomic, copy) NSString *bar;
// qux -> qux!
@property (nonatomic, copy) NSString *qux;

這種事先聲明是否為 null 的定義方法，是不是很像 Swift 中的 optional 機制？然而 OC 時代我們幾乎不會去管變數是否為 nullable 這件事，由此我們可以體會 OC 和 Swift 在語言設計思路上的差異。

其實nullable和nonnull是 Swift 出來之後才引入 OC 的。所以一開始，OC 中的變數預設都是nullable，轉變到 Swift 中，應該就是?。但是這樣轉化代價太大，我們所有變數都要在 Swift 中用if else或者guard來解包。所以為了寫起來方便，Swift 乾脆直接強轉，故而現在這個機制也是一個歷史遺留問題。

• Q: Swift 如此這般導致混編 App 崩潰，沒有提示的情況下程式員必須細細檢查 nil 導致的 bug，這樣設計強制解包的代價是否有點大？

這個 bug 在混編 App 中很容易出現，沒有警告確實帶來很大困擾。實際上這個問題早就在蘋果的開發者論壇上被提出，Swift 組自己也開了個 ticket 要修，可惜最後不了了之。Github 上有人開發出了第三方的工具來解決這個問題。

我個人覺得這個問題蘋果不重視的原因在於 Swift 和 OC 混編只是一個暫時的局面。Swift 取代 OC 是一個時間問題，所以解決混編中的問題都顯得沒有多大意義，在蘋果內部也一直是低優先順序。畢竟現在所有精力應該放在 Swift 上，隨著時間的推移和 OC 的淡出，這個問題也將微不足道。