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

大家好，

Swift 3的正式版已經(jīng)接近完成狀態(tài)了, 是時(shí)候來回顧一下發(fā)布之前的事情, 從中汲取經(jīng)驗(yàn), 并且用來整理一下我們(Swift社區(qū))在今年做的事情了. 總的來說, Swift 3無疑將會(huì)是一個(gè)Amazing的版本, 我們做到的很了不起, 謝謝每一個(gè)為這件事情貢獻(xiàn)力量的人. 比起馬上推進(jìn)那一堆新計(jì)劃, 更重要的是讓我們每個(gè)人從整個(gè)大局來看, 了解自己做到的這些了不起的事情.

Metapoint: 這份郵件很長而且覆蓋了很多主題, 比起直接回復(fù), 最好還是重新開一個(gè)對(duì)話來對(duì)單獨(dú)的一個(gè)話題進(jìn)行討論, 在主題上標(biāo)上[Swift 4]就好了.

Swift 3回顧

每年Swift的開發(fā)都會(huì)跟前一個(gè)版本完全不同, 我預(yù)計(jì)Swift 4也會(huì)延續(xù)這個(gè)習(xí)俗, 為了每一年都要有所收獲有所提升, 我總結(jié)了一下這些關(guān)于Swift 3開發(fā)過程中的觀察和回顧:

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

• 開源同樣也帶來了一些挑戰(zhàn). 我覺得Open Design確實(shí)還是比Closed Design進(jìn)展得更加慢而且更加不可預(yù)計(jì). 然而, 最后的結(jié)果也是比Open Design明顯更勝一籌, 權(quán)衡之下還是很值得的. 所有在Swift Evolution進(jìn)展過程里幫助過我們的人, 送給你們一個(gè)大大的感謝...

• 軟件項(xiàng)目管理(特別是開源項(xiàng)目)一如既往的難以預(yù)料. 我們給Swift 3設(shè)定了一系列過高的目標(biāo), 以至于最后不得不刪減掉一部分, 目標(biāo)定得高是一件好事, 但我們需要更好地告訴大家這些"目標(biāo)"并不是"承諾", 以免大家感到失望.

• 對(duì)少數(shù)幾個(gè)主題的專注. 如果有太多的主題同時(shí)推進(jìn), 那就沒人能持續(xù)跟進(jìn)所有主題了. 核心團(tuán)隊(duì)有必要在一些關(guān)鍵的討論里及時(shí)介入. 在Swift 3的開發(fā)流程里, 很大的一個(gè)問題是, 很多的fork在審核結(jié)束之前都沒有時(shí)間去跟進(jìn)所有的討論.

• 擁有清晰地目標(biāo)是一種解放. 特別是在十二月和一月份這一段時(shí)間里, 我們把目標(biāo)定為適合Swift 3的那些Proposal, 并且同時(shí)開展了好幾個(gè)計(jì)劃, 結(jié)果我們發(fā)現(xiàn)這已經(jīng)大大超出我們能完成的范圍了. 在后來的版本里, 我們有非常明確的目標(biāo)(例如, 不再增加計(jì)劃), 從而讓我們節(jié)約更多精力去專注在那些重要的事情里.

• 讓所有人的滿意是不可能的. 特別是在討論要選哪些Feature和定優(yōu)先級(jí)的時(shí)候, 因?yàn)橛行┟黠@是低優(yōu)先級(jí)的事情. 這是必然的, 因?yàn)椴豢赡茏屗杏腥さ臇|西在一年的開發(fā)里都塞進(jìn)一個(gè)版本里. 所幸, 總會(huì)有另一個(gè)版本, 每一個(gè)新的版本都會(huì)成為一次大改進(jìn)的其中一小步.

以此為背景, 讓我們繼續(xù)說下去!

Swift版本計(jì)劃

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

Swift 4版本規(guī)劃

從Swift 3的經(jīng)驗(yàn)來看, 我們知道我們必須有所選擇. 對(duì)于Swift 4來說, 一個(gè)主要的目標(biāo)就是保持Swift 3.0到4.0的代碼穩(wěn)定(API穩(wěn)定), 并且把標(biāo)準(zhǔn)庫的ABI穩(wěn)定下來. 由此, 核心團(tuán)隊(duì)決定把開發(fā)計(jì)劃分為兩個(gè)階段:

第一階段:

專注代碼穩(wěn)定和ABI穩(wěn)定的工作, 對(duì)于這份工作保持合理的專注. 這意味著任何不會(huì)從根本上更改現(xiàn)有Feature的ABI, 或者對(duì)于標(biāo)準(zhǔn)庫不會(huì)有破壞性的修改在這個(gè)階段都不會(huì)考慮(就是說這個(gè)階段要進(jìn)行的修改都是破壞性的). 例如, 泛型功能里的Condition Confomance是一個(gè)附加功能, 但因?yàn)樗脑黾訒?huì)對(duì)標(biāo)準(zhǔn)庫產(chǎn)生很多影響, 所以這就會(huì)是第一階段的任務(wù). 另一方面, 語法方面的支持對(duì)于現(xiàn)有ABI或者標(biāo)準(zhǔn)庫都不會(huì)有大改變, 所以不太適合在第一階段完成.

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

第二階段:

設(shè)計(jì)和實(shí)現(xiàn)會(huì)在第一階段完成的七七八八, 我們會(huì)根據(jù)剩余的時(shí)間去完成一些比較大型的feature, 我覺得我們應(yīng)該能有時(shí)間去推進(jìn)下邊表里的一部分Feature, 不過得到我們了解具體剩余的時(shí)間才能知道是哪一部分.

除了新Feature之外, 我們也需要重新評(píng)估一下那些我們已經(jīng)接受了的, 會(huì)對(duì)代碼有破壞性, 但還沒加入到Swift 3里的提案. 這些提案沒必要一定要定下來, 我們需要考慮Swift 4的目標(biāo), 根據(jù)每個(gè)提案的具體情況進(jìn)行評(píng)估.

最后, 這跟Swift-Evolution沒有特別的關(guān)系, 只是我個(gè)人想要質(zhì)量和性能兼?zhèn)? 核心團(tuán)隊(duì)想要繼續(xù)提高質(zhì)量, 包括修復(fù)bugs和提高error和warning的算法. 性能優(yōu)化也是我們開發(fā)中一直在做的事情, 包括提高代碼質(zhì)量, 提高標(biāo)準(zhǔn)庫的實(shí)現(xiàn), 加快編譯速度等等. 所有這些工作都可以同時(shí)進(jìn)行.

Swift 4第一階段目標(biāo)

為了專注于代碼和ABI穩(wěn)定, 核心團(tuán)隊(duì)對(duì)于第一階段的規(guī)劃有一個(gè)初步的討論. 這幾個(gè)Feature是我們?cè)诘谝浑A段定為最優(yōu)先的:

• 代碼穩(wěn)定: 這件事情雖然很小, 但很重要. 例如, 我們需要在編譯的時(shí)候加上-std=swift3之類的命令. 我們也提供了一個(gè)途徑去提供一個(gè)不穩(wěn)定的開發(fā)環(huán)境, 以便我們更容易去測(cè)試.

• 適應(yīng)性'Resilience': 這個(gè)Feature提供了一個(gè)方法能夠在ABI穩(wěn)定的情況下, 讓Public API能夠持續(xù)演變. 例如, 我們不想要C++里Fragile Base-Class的問題發(fā)生在Swift里. 很多設(shè)計(jì)和實(shí)現(xiàn)都已經(jīng)在Swift 3里完成了, 但還有一些關(guān)鍵的部分還沒完成, 包括用戶在模型里能看到那些(例如新的屬性).

• ABI細(xì)節(jié)處理: 在現(xiàn)代的代碼模型里, 還有一大堆細(xì)節(jié)需要我們?nèi)フJ(rèn)真評(píng)估和優(yōu)化. 這跟Swift的開發(fā)關(guān)聯(lián)比較大, 而不只是Swift-Evolution的話題.

• 泛型的提高: 我希望Conditional Conformances能夠排在這個(gè)列表的最前面, 還有協(xié)議遞歸約束(Recursive Protocol Requirements)以及更多強(qiáng)力的相關(guān)類型約束. 然而, 絕對(duì)有必要去消除掉剩下的那些 "" 協(xié)議還有以正確的方式長期呈現(xiàn)(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范式: 字符串是一門語言里其中一個(gè)重要的基礎(chǔ)類型. 標(biāo)準(zhǔn)庫的主導(dǎo)團(tuán)隊(duì)有很多提高編程范式和想法, 而且不會(huì)跟Unicode-correct-by-default的范式?jīng)_突. 我們的目標(biāo)是在字符串處理上比Perl做的更好.

• 內(nèi)存所有權(quán)Memory Ownership Model: 在Swift添加類似于[Cyclone](http://www.wikiwand.com/en/Cyclone_(computer)/Rust的那種內(nèi)存所有權(quán)機(jī)制, 在系統(tǒng)編程人員和希望獲取到可預(yù)計(jì)可控制(例如, 實(shí)時(shí)音頻處理)的人里呼聲很大. 跟Swift 4更相關(guān)的是, 這個(gè)Feature的重要性在于它會(huì)從根本上改變ABI. 它解釋了編譯的時(shí)候inout是如何處理的, addressors在ABI里處于哪一層抽象, 影響Swift的運(yùn)行時(shí), 還會(huì)對(duì)類型系統(tǒng)和Name Mangling產(chǎn)生巨大的影響.(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.)

這里面每一個(gè)部分我們都有一些想法了, 但距離一份完整的提案還有很長的一段的路. 我預(yù)計(jì), 也希望這些想法能今早進(jìn)入Swift 4的主要討論里. 甚至, 我們還沒有完整的了解這些將會(huì)如何影響ABI穩(wěn)定, 隨著我們的了解加深也許會(huì)有更多其它具體的影響. 最后, 我們也許會(huì)專注于某個(gè)會(huì)能夠?qū)wift包管理器或者其它Swift.org計(jì)劃具有很多價(jià)值的Feature.

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

就像我前面提到的, 在這個(gè)時(shí)間點(diǎn)我們是不可能知道第二階段的時(shí)候我們的進(jìn)度, 因?yàn)槲覀儾⒉恢肋@段時(shí)間會(huì)有多長. 為了能夠在正式版來臨之前修復(fù)更多bug, 以及讓這一個(gè)版本的生命周期變得更長, 核心團(tuán)隊(duì)更傾向于在Swift 4開發(fā)的時(shí)候延續(xù)Swift 3的開發(fā)周期.

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

• 反射Reflection: 核心團(tuán)隊(duì)承諾過要一些強(qiáng)力的動(dòng)態(tài)feature. 例如Swift 3已經(jīng)完成了數(shù)據(jù)反射data reflection的基礎(chǔ)建設(shè)(已經(jīng)用在了Xcode的內(nèi)存分析). 我們應(yīng)該利用這些基礎(chǔ)設(shè)置去構(gòu)建一個(gè)強(qiáng)大的面向用戶的API. 同樣的, 我們也想要設(shè)計(jì)和構(gòu)建動(dòng)態(tài)函數(shù)反射的runtime以及API的支持.

• First class concurrency: Actors, async/await, atomicity, memory model和相關(guān)的話題. 大家對(duì)于這個(gè)feature有很強(qiáng)烈的需求, 因?yàn)樗鼤?huì)引入所有客戶端, 服務(wù)端以及其它更多方面的新東西. 我們計(jì)劃在第二階段開始正式討論這個(gè), 但很明顯一個(gè)新的并發(fā)模型不會(huì)在Swift 4的開發(fā)周期里做出來, 道理很簡單, 因?yàn)檫@件事情需要花費(fèi)超過一年的時(shí)間去設(shè)計(jì)和實(shí)現(xiàn), 而且我們希望用足夠的時(shí)間去把這件事情做對(duì)做好. 在這件事情完成之前, Memory Ownership Model更容易理解(It also makes sense for the memory ownership model to be better understood before taking this on).

• 泛型增強(qiáng): 泛型計(jì)劃包含了許多令人興奮的泛型系統(tǒng)的改進(jìn), 里面很多都對(duì)于標(biāo)準(zhǔn)庫ABI穩(wěn)定沒有要求, 但這會(huì)讓Swift的泛型更加強(qiáng)力和易于表達(dá).

• Swift模塊穩(wěn)定: 某程度上說我們需要.swiftmodule二進(jìn)制庫穩(wěn)定下來, 以便第三方庫的使用(或者使用另一種機(jī)制). 這里面有很多工作需要完成, 并且需要標(biāo)準(zhǔn)庫的ABI穩(wěn)定.

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

• Property behaviors: 這個(gè)feature可以在現(xiàn)有的Property模型里提供更加強(qiáng)大的抽象. 被推遲的SE-0030計(jì)劃闡釋的很清楚.

• 其他的還有許多, Submodules, implicit promotions between numeric types, 導(dǎo)入C++的API, hygenic macro system, 尾調(diào)用約定(guaranteed tail calls), 可遍歷的枚舉, thows類型, 自定義屬性User defined attributes, 抽象函數(shù)/類abstract methods/classes, 更好的SIMD支持, dynamic for non- at objc(目前的dynamic本身是基于objc的runtime), data parallelism, higher kinded types, ...

• 語法糖: 我不會(huì)把這些全部列出來, 但是總是有很多別的零零碎碎的Proposal提交上來, 特別是那些別的語言用來解決特定問題的方案. 這在Swift 4里優(yōu)先級(jí)別最低.

就這樣, 一份很長的郵件, 包含了一些我們關(guān)于明年要做的事情的想法. 還有一件特別的事情就是我知道Swift 3還沒完成. 當(dāng)破壞性的修改完成之后, 還需要時(shí)間去修復(fù)bug和其他一些優(yōu)化, 這些都很重要.

我覺得現(xiàn)在花點(diǎn)時(shí)間來討論一下我們明年的開發(fā)計(jì)劃還是很有幫助的, 然后把第一階段的feature的概念全部理順, 我們只應(yīng)該去寫那些容易理解的特殊設(shè)計(jì). 看到一大堆提案在那里擺著, 然后沒有足夠的時(shí)間去跟進(jìn)它們, 核心團(tuán)隊(duì)不想陷入這樣的境地, 我們只想處理那些擺在我們面前, 大型的, 重要的, 優(yōu)先級(jí)高的計(jì)劃.

Thank you. 再強(qiáng)調(diào)一次, 如果你想要深入探討某個(gè)話題的話請(qǐng)重新開一個(gè)分支.

-Chris