@property (nonatomic, copy) nsstring *foo;var foo: string!但是這時候問題來了。我們回到上文中的例子，假如 oc 中對foo的使用如下：
@property (nonatomic, copy) nsstring *foo;
- (void)secretfunc
func init() func calclen() -> int
上面這段 swift **執行到calclen()時會崩潰，原因是foo在init()中已經被設成了 nil，而foo在 swift 中是foo!。也就是說，因為 swift 對 oc 變數的強轉，導致了程式的崩潰。這是乙個很容易忽略的問題，因為強轉的時候，xcode 不會給出任何的警告、報錯或是提醒。而我們作為開發者，很容易忽略這樣的錯誤，導致 runtime 的時候直接崩潰。
針對這種情況，我們來討論下面三個問題。
這是乙個有爭議的話題。我個人認為強制解包的方式會督促開發者考慮變數是否為 nil 的問題。在 oc 時代，宣告變數一般不會考慮是否為空的問題；而在 swift 時代，因為其是一門強安全性的語言，在變數定義時，必須確定變數是否為空。一般定義為非空有兩種以下形式：
前者根據初始值強制解包，定義 foo 為非空變數；後者則直接申明 foo 為非空變數。
無論哪種情況，開發者會從一開始就思考處理 nil 時的情況，並在後續開發中一直注意。所以從foo轉化為foo!，你就會思考 oc 中**是否也要處理
nil 的情況；而如果轉化為foo?，nil 也無所謂，而實際可能並不是這樣，nil 的特殊情況考慮會一直忽略，開發中的隱患一直存在，同時也不符合 swift 強安全性的設計思路。
請這樣在 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 乾脆直接強轉，故而現在這個機制也是乙個歷史遺留問題。
我個人覺得這個問題蘋果不重視的原因在於 swift 和 oc 混編只是乙個暫時的局面。swift 取代 oc 是乙個時間問題，所以解決混編中的問題都顯得沒有多大意義，在蘋果內部也一直是低優先順序。畢竟現在所有精力應該放在 swift 上，隨著時間的推移和 oc 的淡出，這個問題也將微不足道。
強制解包看 Swift 的設計
1 property nonatomic,copy nsstring foo 它轉成 swift 就變成了這樣 var foo string 這樣看上去合情合理。swift 中有 string?和 string 兩種形式，但 oc 中沒有 nsstring?和 nsstring 當 swift 無法...
地道的 Swift 解包引導的初始化過程
在 swift users 上，丹問到 最近我在做下面這樣的東西 let dobstring string if let dob dob else有沒有更好更地道的寫法能夠實現同樣的功能呢？我猜serverdateformatter是nsdateformatter的乙個例項。如果是這樣的話，丹想要做...
譯 Swift 裡的強制 inline 註解
譯文出自 掘金翻譯計畫 譯者 iweslie 校對者 cloxnu 在程式設計中，函式內聯是一種編譯器優化技術，它通過使用方法的內容替換直接呼叫該方法，就相當於假裝該方法並不存在一樣，這種做法在很大程度上優化了效能。例如，請看一下 func calculateandprintsomething pr...