強制解包看 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 的淡出，這個問題也將微不足道。