原文鏈接=http://www.jessesquires.com/open-source-swift-weekly-2/
作者=Jesse Squires
原文日期=2015/12/14
譯者=pmst
校對=numbbbbb
定稿=numbbbbb

本周 Swift.org 又有哪些新鮮事呢？ 2015.12.17

Swift.org 社區(qū)已經(jīng)完成其源碼開發(fā)的第二個星期。倘若你期望過個安靜的周末，最好打消這個念頭。要知道項目中仍舊還有一大堆事情需要處理，壓根就沒有減緩的跡象。Swift 團隊繼續(xù)以公開的方式運作，鼓勵開發(fā)者們加入到貢獻的行列中。本周主要是修復(fù)了一些 crashs 以及更多的 Swift 變革提案。閑話少說，開始本周簡訊！

社區(qū)

Craig Federighi 在 John Gruber 的脫口秀節(jié)目中回顧了 Swift 的第一周開源情況。我真的非常喜歡這一期節(jié)目，繼續(xù)被蘋果的開源所深深折服！采訪僅僅只持續(xù)了 30 分鐘左右。Daring Fireball 還提供了完整的采訪對話記錄。

@zhuowei 看起來已經(jīng)在為 Android 提供 Swift 支持了。我真心希望這個項目能火起來。用 Swift 開發(fā) Andriud 應(yīng)用對于移動開發(fā)者來說無疑是一個巨大的勝利！

這里需要澄清上星期的一個紕漏 —— 柯里化函數(shù)將不會被完全移除，僅僅只是語法而已。

Commits 和 pull requests

• Slava Pestov 推送了一個 commit 修復(fù)了編譯器中 91% 的報錯。??（pmst注：本來編譯時有783個錯誤，現(xiàn)在只有74個了?。?/li>
• Dominique d'Argent 在他自己實現(xiàn)的 NSAffineTransform 中首次介紹了 unicode 變量名稱。這也是迄今為止我所看到的唯一一個。誰要是能把使用 ?? 的 pull request 合并到項目中，我非常樂意請他喝杯?或??。
• Bill Abt 和 David Grove 這兩位來自 IBM 的大神為 Swift 和核心標(biāo)準(zhǔn)庫（core libraries）做出了巨大的貢獻！正如 Federighi 在脫口秀所說， IBM 非常樂意將 Swift 應(yīng)用到服務(wù)器端。
• Chris Lattner 修復(fù)了少量的 radars 問題。
• Daninel Duan 提交了一個 pull request 用于優(yōu)化 Set 集合類型。這將提升大約 42% 的執(zhí)行效率?？?！@PracticalSwift 還修正了一堆錯別字。??
• William Dillon 開始為 ARMv7 主機提供支持，譬如 Raspberry Pi,，BeagleBone 以及 Nvidia Tegras.
• Brian Gesiak 一如既往地從事測試 XCTest 框架的工作，他在 corelibs-xctest 項目的提交數(shù)量貢獻榜中位居第三。??

提案

第一個無關(guān) Swift 語言的變革提案已經(jīng)被采納拉！你必須感謝下 Erica Sadun ，是她讓你告別了 C 語言風(fēng)格的 for 循環(huán)。從 Swift2.2 開始，如果使用 C 語言風(fēng)格的 for-loop ，你將收到警告信息，直至 Swift3.0 正式發(fā)布版本中將被徹底移除?！霸诖蠖鄶?shù)情況下，我們一致認同在 Swift 代碼中極少會使用 C 語言風(fēng)格的 for-loop ”，大多數(shù)情況下會選擇使用for-in語句。同時注意到通知中描述了改變將可能導(dǎo)致的兩個潛在問題。

Max Howell，Daniel Dunbar，和 Mattt Thompson 已經(jīng)準(zhǔn)備提交一份提案，為 Swift 包管理器（Swift package manager）增加測試支持！“測試是現(xiàn)代軟件開發(fā)中的一個重要組成部分。緊密耦合的測試集成到 Swift 包管理器中有助于確保一個穩(wěn)定可靠的打包機制。我們建議擴展我們的常規(guī)包目錄布局以適應(yīng)測試模塊?！??

Max Moiseev 建議給 AnySequence.init 增添約束條件，應(yīng)該會在本周審核。我想不出任何理由為什么這個建議不被采納?！笆聦嵣希@些約束應(yīng)該被應(yīng)用到 SequenceType 協(xié)議自身上（盡管就目前來看是不太可能了），同我們預(yù)期的那樣每個 SequenceType 實現(xiàn)都已經(jīng)滿足自身?！?/p>

Divid Hart 建議：要求使用 self 來訪問實例成員，目前正在審核當(dāng)中。如果你現(xiàn)在還未遵守的話，self 關(guān)鍵字總是必須的，即使它可以進行隱式地推斷。譬如， self.view 與簡化的 view。 有關(guān)這個的討論非常多，你可以前往郵件列表和 twitter 看看。我并不是這個建議的擁護者，但是這樣有助于我理解一些參數(shù)。

Erica Sadun 同時發(fā)表了一篇精彩的文章細述了最近的一些提議。

Mailing lists

這里有個非常有意思的話題，有關(guān)動態(tài)方法與靜態(tài)方法的調(diào)度。Chris Lattner 親述：“簡而言之：我真正所要表達的意思是舊的靜態(tài)與動態(tài)比喻至少只是故事的一半。你真正需要的是將編譯模型包含進來，從而由此產(chǎn)生的程序設(shè)計模式加入到故事中，要知道程序設(shè)計模式才是真正所要關(guān)心的?！?/p>

Fabian Ehrentraud 發(fā)起了一個話題，討論了當(dāng)導(dǎo)入無 nullability 屬性的 Objective-C 代碼時如何改善崩潰安全性（crash-safety）。目前，出自 Objective-C 的成員采用隱式可選類型橋接到 Swift 上（例如 view!）。這個提議中建議在導(dǎo)入這些成員時用顯示可選類型替換（view?），這樣可以促使開發(fā)者安全地處理可能的 nil 值。對我來說，這聽起來很不錯。老實講，我不太理解為什么一開始會有隱式解包可選（implicitly unwrapped optionals）存在，這看起來和 Swift 的安全宗旨相悖嘛。

Colin Cornaby 建議將分號（;）完全從 Swift 中移除來順應(yīng)摒棄所有 C-style 語言特性的大勢。正如郵件列表中有人提到，分號在語法上通常可以忽略，但是它們能將類似的語句組合到一行代碼中，提高代碼可讀性。我覺得兩者都有道理，不過目前來看這個討論還沒有引起足夠的重視，短期不太可能修改。
送大家一句話：

Stare long enough into the language design, and the language design stares back into you.
—— Joe Groff