【譯】回顧Swift 3, 展望Swift 4

原文: Looking back on Swift 3 and ahead to Swift 4
作者: Chris Lattner
譯者: kemchenj

大家好，

Swift 3的正式版已經接近完成狀態了, 是時候來回顧一下發布之前的事情, 從中汲取經驗, 並且用來整理一下我們(Swift社群)在今年做的事情了. 總的來說, Swift 3無疑將會是一個Amazing的版本, 我們做到的很了不起, 謝謝每一個為這件事情貢獻力量的人. 比起馬上推進那一堆新計劃, 更重要的是讓我們每個人從整個大局來看, 瞭解自己做到的這些了不起的事情.

Metapoint: 這份郵件很長而且覆蓋了很多主題, 比起直接回復, 最好還是重新開一個對話來對單獨的一個話題進行討論, 在主題上標上[Swift 4]就好了.

Swift 3回顧

每年Swift的開發都會跟前一個版本完全不同, 我預計Swift 4也會延續這個習俗, 為了每一年都要有所收穫有所提升, 我總結了一下這些關於Swift 3開發過程中的觀察和回顧:

• 開源萬歲. 看到這麼一個有活力的社群合作得這麼好真的是讓人覺得很不可思議, 而且看到你們一夜之間幾乎都過來幫忙了. 能和這樣一個才能和熱情兼顧的團隊一起工作真是一件非常棒的事情.

• 開源同樣也帶來了一些挑戰. 我覺得Open Design確實還是比Closed Design進展得更加慢而且更加不可預計. 然而, 最後的結果也是比Open Design明顯更勝一籌, 權衡之下還是很值得的. 所有在Swift Evolution進展過程裡幫助過我們的人, 送給你們一個大大的感謝…

• 軟體專案管理(特別是開源專案)一如既往的難以預料. 我們給Swift 3設定了一系列過高的目標, 以至於最後不得不刪減掉一部分, 目標定得高是一件好事, 但我們需要更好地告訴大家這些”目標”並不是”承諾”, 以免大家感到失望.

• 對少數幾個主題的專注. 如果有太多的主題同時推進, 那就沒人能持續跟進所有主題了. 核心團隊有必要在一些關鍵的討論裡及時介入. 在Swift 3的開發流程裡, 很大的一個問題是, 很多的fork在稽核結束之前都沒有時間去跟進所有的討論.

• 擁有清晰地目標是一種解放. 特別是在十二月和一月份這一段時間裡, 我們把目標定為適合Swift 3的那些Proposal, 並且同時開展了好幾個計劃, 結果我們發現這已經大大超出我們能完成的範圍了. 在後來的版本里, 我們有非常明確的目標(例如, 不再增加計劃), 從而讓我們節約更多精力去專注在那些重要的事情裡.

• 讓所有人的滿意是不可能的. 特別是在討論要選哪些Feature和定優先順序的時候, 因為有些明顯是低優先順序的事情. 這是必然的, 因為不可能讓所有有趣的東西在一年的開發裡都塞進一個版本里. 所幸, 總會有另一個版本, 每一個新的版本都會成為一次大改進的其中一小步.

以此為背景, 讓我們繼續說下去!

Swift版本計劃

下一年, 核心團隊預計可以完成兩個Swift的大版本: 2017年春季推出Swift 3.x, 還有同年秋季釋出的Swift 4. 除了大版本之外, 我們也保證會更新一些小版本(例如 Swift 3.0.1)來修復bugs, 或者是核心庫需要的服務, 或者其他Swift.org的計劃.

Swift 4版本規劃

從Swift 3的經驗來看, 我們知道我們必須有所選擇. 對於Swift 4來說, 一個主要的目標就是保持Swift 3.0到4.0的程式碼穩定(API穩定), 並且把標準庫的ABI穩定下來. 由此, 核心團隊決定把開發計劃分為兩個階段:

第一階段:

專注程式碼穩定和ABI穩定的工作, 對於這份工作保持合理的專注. 這意味著任何不會從根本上更改現有Feature的ABI, 或者對於標準庫不會有破壞性的修改在這個階段都不會考慮(就是說這個階段要進行的修改都是破壞性的). 例如, 泛型功能裡的Condition Confomance是一個附加功能, 但因為它的增加會對標準庫產生很多影響, 所以這就會是第一階段的任務. 另一方面, 語法方面的支援對於現有ABI或者標準庫都不會有大改變, 所以不太適合在第一階段完成.

第一階段的工作很重要(下文有更多細節), 所以我們春季之前都會比較忙碌.

第二階段:

設計和實現會在第一階段完成的七七八八, 我們會根據剩餘的時間去完成一些比較大型的feature, 我覺得我們應該能有時間去推進下邊表裡的一部分Feature, 不過得到我們瞭解具體剩餘的時間才能知道是哪一部分.

除了新Feature之外, 我們也需要重新評估一下那些我們已經接受了的, 會對程式碼有破壞性, 但還沒加入到Swift 3裡的提案. 這些提案沒必要一定要定下來, 我們需要考慮Swift 4的目標, 根據每個提案的具體情況進行評估.

最後, 這跟Swift-Evolution沒有特別的關係, 只是我個人想要質量和效能兼備, 核心團隊想要繼續提高質量, 包括修復bugs和提高error和warning的演算法. 效能優化也是我們開發中一直在做的事情, 包括提高程式碼質量, 提高標準庫的實現, 加快編譯速度等等. 所有這些工作都可以同時進行.

Swift 4第一階段目標

為了專注於程式碼和ABI穩定, 核心團隊對於第一階段的規劃有一個初步的討論. 這幾個Feature是我們在第一階段定為最優先的:

• 程式碼穩定: 這件事情雖然很小, 但很重要. 例如, 我們需要在編譯的時候加上-std=swift3之類的命令. 我們也提供了一個途徑去提供一個不穩定的開發環境, 以便我們更容易去測試.

• 適應性`Resilience`: 這個Feature提供了一個方法能夠在ABI穩定的情況下, 讓Public API能夠持續演變. 例如, 我們不想要C++裡Fragile Base-Class的問題發生在Swift裡. 很多設計和實現都已經在Swift 3裡完成了, 但還有一些關鍵的部分還沒完成, 包括使用者在模型裡能看到那些(例如新的屬性).

• ABI細節處理: 在現代的程式碼模型裡, 還有一大堆細節需要我們去認真評估和優化. 這跟Swift的開發關聯比較大, 而不只是Swift-Evolution的話題.

• 泛型的提高: 我希望Conditional Conformances能夠排在這個列表的最前面, 還有協議遞迴約束(Recursive Protocol Requirements)以及更多強力的相關型別約束. 然而, 絕對有必要去消除掉剩下的那些 “_” 協議還有以正確的方式長期呈現. (However, the standard library gurus need to break down what is absolutely essential to finally eliminate the rest of the “_” protocols and manifest the public API of the standard library in the right way for the long term.)

• 新的字串API正規化: 字串是一門語言裡其中一個重要的基礎型別. 標準庫的主導團隊有很多提高程式設計正規化和想法, 而且不會跟Unicode-correct-by-default的正規化衝突. 我們的目標是在字串處理上比Perl做的更好.

• 記憶體所有權Memory Ownership Model: 在Swift新增類似於Cyclone/Rust的那種記憶體所有權機制, 在系統程式設計人員和希望獲取到可預計可控制(例如, 實時音訊處理)的人裡呼聲很大. 跟Swift 4更相關的是, 這個Feature的重要性在於它會從根本上改變ABI. 它解釋了編譯的時候inout是如何處理的, addressors在ABI裡處於哪一層抽象, 影響Swift的執行時, 還會對型別系統和Name Mangling產生巨大的影響.(It informs code generation for “inout”, how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.)

這裡面每一個部分我們都有一些想法了, 但距離一份完整的提案還有很長的一段的路. 我預計, 也希望這些想法能今早進入Swift 4的主要討論裡. 甚至, 我們還沒有完整的瞭解這些將會如何影響ABI穩定, 隨著我們的瞭解加深也許會有更多其它具體的影響. 最後, 我們也許會專注於某個會能夠對Swift包管理器或者其它Swift.org計劃具有很多價值的Feature.

Swift 4第二階段 可能的努力方向

就像我前面提到的, 在這個時間點我們是不可能知道第二階段的時候我們的進度, 因為我們並不知道這段時間會有多長. 為了能夠在正式版來臨之前修復更多bug, 以及讓這一個版本的生命週期變得更長, 核心團隊更傾向於在Swift 4開發的時候延續Swift 3的開發週期.

所以說, 我覺得我們應該能夠完成相當一部分新Feature, 我對這件事情很樂觀. 給你一些它們的概要, 我整理了一份列表, 但記住, 這不是一份計劃或者承諾, 這只是一份普遍要求的feature的列表:

• 反射Reflection: 核心團隊承諾過要一些強力的動態feature. 例如Swift 3已經完成了資料反射data reflection的基礎建設(已經用在了Xcode的記憶體分析). 我們應該利用這些基礎設定去構建一個強大的面向使用者的API. 同樣的, 我們也想要設計和構建動態函式反射的runtime以及API的支援.

• First class concurrency: Actors, async/await, atomicity, memory model和相關的話題. 大家對於這個feature有很強烈的需求, 因為它會引入所有客戶端, 服務端以及其它更多方面的新東西. 我們計劃在第二階段開始正式討論這個, 但很明顯一個新的併發模型不會在Swift 4的開發週期裡做出來, 道理很簡單, 因為這件事情需要花費超過一年的時間去設計和實現, 而且我們希望用足夠的時間去把這件事情做對做好. 在這件事情完成之前, Memory Ownership Model更容易理解(It also makes sense for the memory ownership model to be better understood before taking this on).

• 泛型增強: 泛型計劃包含了許多令人興奮的泛型系統的改進, 裡面很多都對於標準庫ABI穩定沒有要求, 但這會讓Swift的泛型更加強力和易於表達.

• Swift模組穩定: 某程度上說我們需要.swiftmodule二進位制庫穩定下來, 以便第三方庫的使用(或者使用另一種機制). 這裡面有很多工作需要完成, 並且需要標準庫的ABI穩定.

• 新的文字feature: 常規的書寫方式, 多行字串字面值連線multi-line string literals之類的. 有這些功能會讓Swift更加吸引那些需要文字處理和使用web技術的人. 這也會幫助完成字串的模型.

• Property behaviors: 這個feature可以在現有的Property模型裡提供更加強大的抽象. 被推遲的SE-0030計劃闡釋的很清楚.

• 其他的還有許多, Submodules, implicit promotions between numeric types, 匯入C++的API, hygenic macro system, 尾呼叫約定(guaranteed tail calls), 可遍歷的列舉, thows型別, 自定義屬性User defined attributes, 抽象函式/類abstract methods/classes, 更好的SIMD支援, dynamic for non- at objc(目前的dynamic本身是基於objc的runtime), data parallelism, higher kinded types, …

• 語法糖: 我不會把這些全部列出來, 但是總是有很多別的零零碎碎的Proposal提交上來, 特別是那些別的語言用來解決特定問題的方案. 這在Swift 4裡優先順序別最低.

就這樣, 一份很長的郵件, 包含了一些我們關於明年要做的事情的想法. 還有一件特別的事情就是我知道Swift 3還沒完成. 當破壞性的修改完成之後, 還需要時間去修復bug和其他一些優化, 這些都很重要.

我覺得現在花點時間來討論一下我們明年的開發計劃還是很有幫助的, 然後把第一階段的feature的概念全部理順, 我們只應該去寫那些容易理解的特殊設計. 看到一大堆提案在那裡擺著, 然後沒有足夠的時間去跟進它們, 核心團隊不想陷入這樣的境地, 我們只想處理那些擺在我們面前, 大型的, 重要的, 優先順序高的計劃.

Thank you. 再強調一次, 如果你想要深入探討某個話題的話請重新開一個分支.

-Chris