Chris Lattner 對 Swift 3 的總結與對 Swift 4 的展望

做者：Erica Sadun，原文連接，原文日期：2016-07-29
譯者：wiilen；校對：saitjr；定稿：CMB

Chris Lattner 寫了一篇文章：回顧 Swift 3，展望 Switf 4，如下是這篇文章的關鍵內容：

• 開源大有益處，但沒法讓全部人滿意。

• Swift 3 將在 2016 年秋到來。Swift 3.x 會在 2017 年春公佈，Swift 4 會在 2017 年秋髮布，這其中不包括修復 bug、提高兼容性之類的小更新（例如 3.0.1）。

• Swift 4 在交付時必定會保障代碼的穩定性，增長容錯性、ABI，優化泛型與字符串等等。

• 語法糖的優先級最低，沒有提上日程。

• 安排進度有些困難。開發的目標並不是是對交付的保證。從一開始安排計劃與進度就是最主要的事。

下面是全文：

---

你們好呀，

Swift 3 的正式版已經基本完成，是時候讓咱們回顧一下這個版本了，從開發過程當中汲取經驗，並用於總結咱們（Swift 社區）在這一年內所作的事。整體上來講，Swift 3 毫無疑問將是一個 amazing 的版本，咱們完成了不少出色的工做。感謝全部爲它付出的人。相比於馬上着手推動新計劃，盤點過去、展望將來一樣重要。

提示：這封 email 長得嚇人，其中涵蓋了各方面的話題。比起直接回復，更好的選擇是開一個新話題來討論。只需在主題上標記「［Swift 4］」便可。

Swift 3 回顧

每一年 Swift 的新版本都與前一年徹底不一樣，我但願 Swift 4 能繼續保留這個傳統。爲了每年都有提高與進步，如下是一些對 Swift 3 的回顧與建議：

• 開源有許多好處。見證一個充滿活力的團隊合做得如此之好，你們幾乎徹夜爲其付出，讓人難以想象、充滿驚喜。與這樣一個才華橫溢並充滿熱情的團隊合做，實在是太棒了！

• 開源也帶來挑戰。比起「閉源設計」，「開源設計」 進度更慢且更加不可預料，我想這麼說應該是公允的。然而，開源的結果明顯更好，所以權衡之下開源是值得的。「感謝大家」，獻給全部幫助 Swift 發展進化的人。

• 預估 軟件開發的進度（特別是開源項目）依然困難到近乎不可能。咱們在着手開發 Swift 3 的時候設立了許多高目標，在後期不得不進行修整。設立一些高目標是好事，但咱們須要在溝通上更努力，讓其餘人知道「目標」不等於「承諾」，避免誤導他們。

• 整個社區得益於在有限的主題上保持專一，由於若是有太多事項同時進行，沒有人能夠持續跟進全部部分。參與到前面所提的關鍵討論中，對核心團隊而言很是重要。在 Swift 3 的開發週期中，不少人在代碼評審結束前都沒有時間來跟進討論，這是一個問題。

• 確立清晰的目標是一種解脫。特別是在去年十二月到今年一月，咱們大體圈出了那些適合放入 Swift 3 的點子，同時開啓了幾個項目，這些項目最後遠超出咱們的能力範圍。在後來的版本中，咱們確立了幾個具體目標（好比「再也不加入新計劃」），使全部人能更輕鬆地關注重要事項。

• 皆大歡喜是不可能的，尤爲是在咱們討論優先開發哪些功能時，由於這會下降其餘一些功能的優先級。這是一個無解的局面，由於咱們並無辦法將全部有意思的工做都放在一個只有一年長的開發週期中。幸運的是，未來「總會有下一個版本」，每個新版本都會加入一些重大的改進。

在上述回顧的基礎上，咱們來展望將來！

Swift 發佈計劃

在接下來一年裏，核心團隊預計會發布兩個主要的版本：2017 年春發佈 Swift 3.x，2017 年秋髮布 Swift 4。除了主要版本以外，咱們也會發布一些小的更新（如 Swift 3.0.1）來修復 Bug，或知足核心庫的需求，或其餘的 swift.org 的項目。

Swift 4 發佈計劃

從咱們在 Swift 3 中得到的經驗來看，咱們須要挑出一些重點。對 Swift 4 來講，主要目標是從 3.0 開始要保證交付的代碼的穩定性，併爲標準庫提供 ABI 的穩定性。所以，核心團隊決定在接下來的一年中實施兩個階段的計劃：

第一階段：專一於提高代碼及 ABI 穩定性，全心投入只完成這項必要的工做。這意味着若是一些功能不會從根本上改變現有語言特性的 ABI ，或是對標準庫的 ABI 進行了破壞性的改動，那麼現階段都不會考慮開發它們。舉個例子，泛型中的條件一致性（Conditional conformances）是一個附加特性，但因爲它會對標準庫形成衆多更改，咱們在第一階段就要實現它。另外一方面，正則表達式不會對現有 ABI 形成影響，也不會給標準庫帶來大量改動，因此第一階段不會考慮它。

第一階段的工做很是重要（下面會詳細介紹），因此春季以前咱們大概一直會很忙。

第二階段：當第一階段功能的設計與實現工做較好得完成以後，咱們將基於剩餘時間，選擇一些大型的功能進行開發。我樂觀估計將有剩餘時間，來從長長的功能列表中選幾個來開發，但具體選哪幾個，得看最後剩多少時間。

除了新功能以外，咱們也須要從新評估那些在 Swift 3 中還沒有實現的、對代碼形成破壞性變更的提案。這些提案不必定會被經過，咱們須要在 Swift 4 的基礎上來評估它們，挨個決定如何處理。

最後，雖然與 Swift 的進步沒有特別大的關係，但我想提一提質量與性能問題。核心團隊想要進一步提高質量，包括修復編譯器的 Bug、改進錯誤與警告檢測功能。性能是開發中另外一個須要重視的部分，包括提高編譯後的代碼質量，改善標準庫的實現，加快編譯速度等。這些工做在任何開發階段都須要重視。

Swift 4 第一階段目標

爲了專一於代碼與 ABI 的穩定性，核心團隊對第一階段的工做有一個初步的討論。下面是咱們對第一階段功能排序後的結果：

• 代碼穩定性相關功能：這一部分工做量相對較小，但很重要。舉個例子，咱們須要相似於「-std=swift3」的編譯器標誌。咱們也須要一個新方法來開啓一些大型的功能，這些功能尚在開發，並不穩定，有了這個方法，調試會更簡單。

• 適應力（Resilience）：這個功能提供了一種方式，在保證 ABI 穩定性同時，公有 API 能夠隨時間改進。一個例子，咱們不想讓 C++ 的「fragile base class」 問題發生在 Swift 中。更多設計與實現上的工做已經在 Swift 3 中完成了，但仍有重要工做未完成，包括模型中用戶可見的部分（例如新的屬性）。

• ABI 細節：代碼生成模型中仍有大量細節須要審覈與改進。這一部分與 Swift 開發更相關，與 Swift 的演進關係不大。

• 泛型改進須要在標準庫的基礎上進行：我但願條件一致性能在功能清單中處在最高位置，遞歸協議要求（recursive protocol requirements）與更強大的關聯類型約束能處在隨後的相近位置。然而，標準庫的開發者們須要大量時間來解析出相當重要的部分，最終消除那些「_」協議，並正確展示標準庫中的公有 API。

• 字符串相關改進：字符串是 Swift 中最重要的基本類型之一。標準庫的開發者有不少點子，能改進它的編程範式而不影響到提供 unicode-correct-by-default 範式。咱們的目標是在字符串處理上比 Perl 作得更好！

• 內存全部權模型（Memory ownership model）：許多系統開發者，以及想要可預測及肯定性的性能（如在實時音頻處理中）的人們，都很是但願 Swift 中能有一個（可選的）相似於 Cyclone / Rust 的內存全部權模型。從 Swift 4 的目標上來講，這個功能很重要，由於它從根本上改變了 ABI。這一模型會通知編譯器「inout」事件的產生，解釋底層「addressors」如何在 ABI 中運做，影響 Swift runtime，並對類型系統及命名管理產生顯著影響。

咱們對上面這些功能都有了一些想法，但它們在正式成爲提案以前仍有很長路要走。我期待它們會在 Swift 4 的早期成爲主要討論內容。不只如此，因爲咱們尚未所有找出那些影響 ABI 穩定性的部分，可能還有其餘須要增長的條件。最後，咱們也可能選擇其餘一些對 SwiftPM 這個包管理器，或其餘對 swift.org 有高價值的小功能。

可能的 Swift 4 第二階段工做

如我以前所提到的，在這個點上不可能知道還有多少時間留給第二階段，所以也不知道第二階段能完成哪些工做。核心團隊也但願比 Swift 3 更早完成 Swift 4 開發版的合流，以便在版本發佈以前有更多時間修復 BUG，仔細斟酌。

也就是說，我樂觀估計咱們可以挑一些你們都想要的新功能來開發。爲了讓你對這些功能有個概念，我列了張表。請注意這並非開發的計劃或承諾，而只是列了一些你們都但願有的功能：

• 反射：核心團隊正致力於爲 Swift 添增強大的動態機制。舉個例子，Swift 3 中大體完成了數據反射的基礎結構（已被用在 Xcode 的 memory debugger 中）。咱們應在這些基礎結構之上，搭建一些強大的面向用戶的 API。一樣，咱們想要設計並實現動態方法反射的 runtime 與 API 支持。

• 最重要的併發：Actors、異步 / 等待（async / await）、atomicity、內存模型（memory model）以及相關話題。這些是你們都想要的，由於有了它們，就能夠在客戶端、服務端等之上開發更多新功能。咱們計劃在第二階段正式討論這件事，但很是明確地告訴你們，新的併發模型在 Swift 4 發佈時還沒法完成。咱們須要超過一年的時間來進行設計與開發，咱們也但願把這件事作好作對。須要這麼多時間，也是由於在開發內存全部權模型以前能更深刻的理解它。

• 泛型改進：泛型的開發計劃中包含來許多激動人心的功能，能改進現有泛型系統。在提高標準庫的 ABI 穩定性時並不須要這些功能，但它們會使 Swift 的泛型更增強大易懂。

• .swiftmodule 的穩定性：在某些方面咱們須要使「.swiftmodule」的二進制文件格式穩定下來（或用不一樣的機制替代它），容許開發第三方的二進制框架。這個工做量很大，並須要標準庫 ABI 保持穩定。

• 新的腳本功能：包括正則表達式、多行字符串字面量等。有了這些功能，Swift 在密集型文本處理任務及搭建 web 等方面會更有吸引力。這些功能也有助於完善字符串模型。

• 屬性行爲：這一功能承諾爲現有屬性模型提供強大的抽象能力。在被推遲的 SE-0030 提案中對它有完整描述。

• 其餘功能：子模塊、數值類型間的隱式轉換、導入 C++ API、hygenic macro system、尾調用約定、枚舉類型遍歷、帶類型的「thorws」、用戶定義屬性、抽象方法 / 類、更好的 SIMD 支持、非 @objc 的動態支持、支持數據並行、更高等級的類型...

• 語法糖：我不會把它們所有列出來，但有大量零散的小提案會常常出現，特別是那些其餘語言中出現過、用於解決特定問題的。這些在 Swift 4 開發中都屬於最低優先級。

好了，這是一封超長的郵件，列出了一些關於明年要作的事的想法與點子。有一點要提醒一下你們，目前 Swift 3 還沒有完成。當對代碼的破壞性改動（將要）完成時，須要留有一些時間來修復 Bug 並提高代碼質量，這對於正式發佈版很重要。

我認爲若是咱們立刻花一些時間來討論明年開發計劃的一些基本事項，會頗有幫助，而後再從概念上分解一些第一階段的特性。只有在對它們有深刻了解以後，咱們才應該開始寫一些提案。核心團隊不但願被太多提案淹沒，以致於沒法跟蹤它們的進展，或讓咱們沒法專一於那些高優先級的項目中。

謝謝你們。再次提醒一下，若是你們想要更深刻討論某個話題，請從新開一個分支。

本文由 SwiftGG 翻譯組翻譯，已經得到做者翻譯受權，最新文章請訪問 http://swift.gg。