免費(fèi)AI編程助手
[譯]Swift 的類型體系
Brent Simmons 在 解決目前不存在的問題，就好像問題存在一樣 中說到：
Swift 的類型體系解決了我沒碰到的一個(gè)問題。
對(duì)這句話我深有同感，而且我敢打賭很多其他的 Objective-C 開發(fā)者也會(huì)這樣覺得。
在我剛開始嘗試使用 Swift 時(shí)，編譯器似乎經(jīng)常和我做對(duì) 1 。但隨著我對(duì)這門語言越來越熟悉，情況也隨之變得好起來，但是有時(shí)它奇怪的錯(cuò)誤信息還是會(huì)讓我覺得它是一個(gè)難以取悅的任性小孩。
在這樣的情況下，Swift 嚴(yán)格的類型檢查所帶給你的好處相比你為了讓代碼運(yùn)行所付出的努力就少之又少了。即便如此，它的類型體系還是在去年成長到了讓我再也不想錯(cuò)過它的程度。
Swift 更好理解
相比 Objective-C 我更喜歡 Swift 最大的原因不是他的類型體系，而是一些更平凡的特性
- 一等公民值類型。可以把
integer或者struct在不使用object包裝的情況下就放到array中，這可以說是大贏，因?yàn)檫@意味著我們可以對(duì)這些類型進(jìn)行擴(kuò)展。 - 枚舉有關(guān)聯(lián)值。還有元組。在 Swift 中構(gòu)建數(shù)據(jù)結(jié)構(gòu)模型變得更加清晰。
- 模式匹配。
- 更清晰的語法且沒有頭文件。
簡(jiǎn)而言之，Swift 是現(xiàn)代語言，而 Objective-C 顯然不是。
如果 Apple 在去年發(fā)布了真正的 “Objective-C 3.0”，在保留 Obj-C 動(dòng)態(tài)特性的情況下使其現(xiàn)代化 2 ，我將會(huì)更加開心并且可能永遠(yuǎn)不會(huì)主張更加靜態(tài)的類型檢查。畢竟，“我知道我所做的事情，而且我永遠(yuǎn)不會(huì)因?yàn)閿?shù)組里面包含意外類型而導(dǎo)致錯(cuò)誤?！?/p>
Hole-Driven 開發(fā)
但是 Apple 給了我們 Swift， 而不是 Objective-C 3.0。Swift 的發(fā)布促使我去了解其他有同樣類型體系的語言，比如 Haskell，ML 和 Scala。我從那些社區(qū)學(xué)到的特別的一點(diǎn)就是 hole-driven （或編譯驅(qū)動(dòng)）開發(fā) ：不要把編譯器當(dāng)作需要你對(duì)抗的一股力量，而是把它當(dāng)作可以解決你問題的一件神器，根據(jù)類型一步一步滴來。
Hole-Driven 開發(fā)在構(gòu)建數(shù)據(jù)結(jié)構(gòu)模型和數(shù)據(jù)轉(zhuǎn)換時(shí)可以說是夢(mèng)幻般的技術(shù)（ Haskell 和它的同類尤其擅長），而且盡管還有可提升的潛力，它在 Swift 中依然表現(xiàn)滴相當(dāng)棒。煩人的編譯器和有益的編譯器最關(guān)鍵的不同點(diǎn)在于它的錯(cuò)誤信息是不是易于理解，而很多 Swift 的診斷信息仍然相當(dāng)神秘 3 。
對(duì)于典型的 GUI 編程， 編譯驅(qū)動(dòng)開發(fā)可能沒那么有用，盡管我認(rèn)為這主要?dú)w根于 Cocoa API 的設(shè)計(jì)而不是編譯驅(qū)動(dòng)開發(fā)固有的限制。像 ReactiveCocoa 這樣的庫就向我們展示了類型體系（在一定程度上說應(yīng)該是清晰的語法）設(shè)計(jì)出來的 API 是什么樣的。當(dāng)你可以依賴一個(gè)幸虧有泛型的編譯器來做多步的 復(fù)雜信號(hào)變換 ，保證結(jié)果的正確性將會(huì)變得更加簡(jiǎn)單。現(xiàn)在我發(fā)現(xiàn)在 Objective-C 中寫這樣的代碼要難得多（隨后也更難理解），因?yàn)槲倚枰谖夷X海中記更多的東西。
自動(dòng)文檔
嚴(yán)格的類型體系帶來的另外一個(gè)巨大好處就是做為副產(chǎn)品生成的自動(dòng)文檔。做為 Apple 平臺(tái)上的開發(fā)者，我們?cè)L問不到我們最常使用的庫的源代碼，所以我們需要依賴文檔。編譯器強(qiáng)制 API 設(shè)計(jì)者提供的信息越多，使用 API 的人就越方便。單可選注釋就給 Cocoa 的文檔提供了極大的提升 4 。想象一下如果所有 Cocoa 的 API 的方法參數(shù)和返回值類型都是 id。頭文件基本上就沒什么用了。
總結(jié)
在強(qiáng)制我自己對(duì)類型進(jìn)行非常仔細(xì)的思考之后，我發(fā)現(xiàn)我 Swift 代碼的設(shè)計(jì)更好了，也更容易維護(hù)了。我對(duì)我代碼的正確性也更加有自信了，而且更奇怪的是：寫起來也更有趣了?。≒S：此處有強(qiáng)烈的補(bǔ)腎丸廣告即視感）
Swift 仍然在起步階段。有時(shí)它可能會(huì)讓你沮喪，但是隨著時(shí)間的推移編譯器提示的錯(cuò)誤信息會(huì)更友好，甚至可以讓你的代碼更加合理。比如說我們都在糾結(jié)的一個(gè)例子，并發(fā)：如果編譯器可以靜態(tài)滴證明你的多線程代碼不存在沖突，那就是一個(gè)巨大的優(yōu)勢(shì)。Swift 現(xiàn)在還不能做，但是 Rust 可以 。對(duì)次我相當(dāng)興奮。
<a name="1">1.這也是我覺得 Swift 果斷不是一門易學(xué)（易教）語言的原因之一。另外一個(gè)就是復(fù)雜的標(biāo)準(zhǔn)庫</a>
<a name="2">2.我們幾十年來都在使用“沒有 C 的 Objective-C”，而是以 Smalltalk 的形式</a>
<a name="3">3.毫無疑問，至少有一部分原因是我對(duì)語言比較陌生</a>
<a name="4">4.我需要提醒大家的是注釋是不保證正確性的，所以嚴(yán)格滴說它們沒有頭文件注釋可靠。也許有人會(huì)認(rèn)為僅僅一個(gè)嚴(yán)格的編譯器就可以強(qiáng)制讓 Apple 的文檔更加精確。</a>
更多建議：