【譯】回顧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