歡迎來到開源周刊14期！效仿 Dave Verwer，我也對 Xcode7.3 最后發布版本進行了預測 —— 包括 iOS9.3，OS X10.11.4 以及 watchOS2.2 三個版本。Xcode7.3 將包含最終版本的 Swift2.2 語法。核心團隊可能會在下周一解開謎底。ps：Apple 將于 3.21 舉辦 “Let Us Loop You In” 的發布會。
啟動任務
來自 Ehsan Hahromi 的建議：
來自 Daniel Eggert 的建議：
此外，上周周報中 Brian Gesiak 提出的問題依然懸而未決：
- SR-906 —— 允許 XCTestCase.continueAfterFailure 進行可寫
- SR-875 —— 促使 swift-corelibs-xctest 的功能測試正則匹配，使得用起來更像 FileCheck
提交任務啦！倘若你想要提交任務，請新建一個 issue 或 pull request。同樣你還可以在 tweet 上 @swiftlybrief。任務可以有不同的難度，但通常要求適合初學者。??
倉庫
本周新增了 apple/cups 倉庫，這是來自官方版本的 CUPS 資源。如若你對此不是很熟悉，簡單來說CUPS是基于標準的，為Apple OS X和其他類 UNIX 操作系統開發的開源打印系統。此代碼已經存在了十幾年（自1999年開始），所以看著它“與時俱進”，將項目遷移到GitHub真的很不可思議。“應大眾的要求，CUPS 現已托管于 GitHub 上。所有 bugs 都一并遷移到了 GitHub 的 issue 追蹤器上，同時更新了 git 倉庫，包括自1.7.0版本開始丟失的發布標簽。在未來幾周里，我們還將把 cups.org 網站搬遷到 GitHub 上進行托管。” 我想知道我們是否會見證更多來自 Apple 的開源項目搬遷到 GitHub 上呢？希望如此吧。??
Commits 和 PR
來自 objc.io 的 Daniel Eggert 提交了在 corelibs-foundation 中實現 NSHTTPURLRepsonse 的 pr。??
Max Howell 將 Swift Package Manager 移植到 Swift3 版本上了。
Nate Cook 為基于新索引模型的集合打上 .flatten 補丁。
John Regner 遞交了一個 PR，關于將 SourceKit 中的代碼格式化邏輯部分移動到 libIDE中，作為 SR-146 提案的一部分（該提案旨在創建一個 swift-format 工具）。
John Holdsworth 修復了 Xcode7.3b5 版本中關于 SourceKit 使用 “Quick Help” 崩潰的問題。?? 我從未聽說過SourceKit 會崩潰。 ??
@practicalswift 新增了一些編譯崩潰的測試案例。
Janek Spaderna 修復了 AST/sema 中的崩潰問題：當你在 where 從句中引用枚舉用例（enum case）會導致 crash。目前解決方案為打印錯誤信息而非直接崩潰。該問題看起來最初是由 @practicalswift 發現的。
提案
Erica Sadun 的 SE-0039 提案：Modernizing Playground Literals 已經正式被 Swift3.0 采納了。“社區和核心團隊一致認為該項提案增加了 swift 編程語言的一致性。” Chris Lattner 將該任務歸檔到 SR-917 用于追蹤進度。“對于那些致力參與編譯器開發的小伙伴，這將是一個意義非凡的啟動任務。”??
Jesse Rusak 的 SE-0037 提案：關于理清注釋和運算符之間的交互問題已經正式被采納了。“社區中幾乎沒有相關討論，但核心團隊和社區參與者都表示贊同，認為這將解決語言中的一個角落問題。”你可以在 SR-960 關注工作的進度。
Jake Carter 和 Erica Sadun 的 SE-0046 提案：為包括首標簽（first label）在內的所有參數建立一致的標簽行為建議，已正式被 Swift 3 采納了。“社區和核心團隊一致認為該提案有助于產生積極的影響，不但增加了語言的可預測性和一致性，而且移除了一個常見的混淆問題。”??，該項任務可在SR-961追蹤查看。
llya Benlenkiy 的 SE-0025 提案：Scoped Access Level 被返回做進一步的修訂，這看起來核心團隊還是對此很感興趣的。雖然他們認為這符合 Swift 的開發方法，但是他們還是擔心local和private之間造成混淆。
所要求的修訂包含提及的
local關鍵字。核心團隊認為目前private關鍵字能夠很恰當地描述提及的功能性。其他具有私有訪問說明符的編程語言密切結合提出的局部性行為。所以這樣的改變將有助于減少開發者語言使用的切換，同時正如核心團隊所認為的，private關鍵字所要描述的內容更合適。
具體而言，核心團隊提出了一個修訂版本的提案，旨在將現有的
private關鍵字語義更改成提及的local關鍵字，并為現有的私有語義引入一個新的名稱，更明確地表述文件的私有訪問。正因為改動影響面太廣，因此核心團隊認為還需做進一步的公開審查。
Michael IISeman 的 SE-0044 提案：“作為成員導入”提案目前處于審核狀態。“該提案旨在為 C API 作者提供一種機制，在導入 Swift 類型時指定導入函數和參數成員的功能。同時它還為那些遵循一致性，且具有嚴格命名約定的 API 提供一個自動推斷選項。”
Joe Groff 的 SE-0042 提案：“ Flattening the function type of unapplied method references” 目前處于審核狀態。“我們應該對一個未應用的（unapplied）方法引用進行類型調整，通過平整化（flatten）函數傳入值方式替換掉原先的 curried 類型。這將大大使得 未應用的（unapplied）方法在實際 Swift 庫中更具可讀性和實用性，同時還應支持突變函數。”當前我們可以通過往reduce方法傳入全局運算符+來實現，譬如：arrayOfInts.reduce(0,combine:+)。但是你卻無法通過傳入類似Set.Union二進制方法來做同樣的事，譬如：arrayOfSets.reduce([], combine: Set.union)。這項提案將將使得后者成功可能。
Andrew Benett 的 SE-0043 提案：“在多個匹配 case 標簽中聲明變量”目前正在審核中。“ Swift2 已經實現了 case選項中多條件匹配。但是不適用case用例中聲明變量的情況。提案的改動不但可以減少重復的代碼，同時還將減少錯誤發生。當未定義變量時，它和多模式匹配保持一致。”
Adrian Kashivskyy 和 Erica Sadun 的 SE-0047 提案：“Defaulting non-Void functions so they warn on unused results”目前正在審核中。“就 Swift 目前情況，通過為方法和函數標注 @warn_unused_result 來告知編譯器對于返回類型為 non-void 的方法或函數，其返回值應該被使用（譯者注：也就是函數返回值也應該被利用，丟棄會產生警告）。這是一個肯定的聲明。在它的情況下，忽略的結果不產生警告或錯誤。[...]未使用的結果更能夠向編程者說明錯誤，而不會在 mutating 和 non-mutating 函數對之間產生混淆。該提案使得 'warn on unused result' 作為 Swift 方法和函數的默認行為。
郵件列表
Max Howell 發郵件稱，想要恢復此前SPM中的一個第三方測試框架協議提案。
Daniel Eggert 開啟一個有關使用封裝libcurl來實現 NSURLSession 的話題。Philippe Hausler 回復了一些關于 corelibs-foundation 和 移植 API 到 Linux 的一些趣聞。
由 David Hart 開啟的話題仍在繼續，關于“Referencing Objective-C key-paths”草案。這將消除另一個 KVC/KVO 中使用 stringly-typed 的代碼。“這項提案旨在使用 key-paths 進行代碼修改時，能夠提高安全性和韌性，通過引入一個編譯器來檢查表達式實現。”社區反饋一片好評。
Yuta Koshizawa 建議為 Result<T> 增加 throws 語法糖，“將拋出（throws）和 結果（result）統一成單個特性，以保持語言簡潔性。”Joe Groff 通過深思熟慮之后，回應核心團隊關于 Swift 中錯誤處理模型決定的更多細節，并附上了原因。
我們廣泛討論了在內部添加一個 Result 類型，但是最終無法自圓其說。唯一我們可以預見的使用案例是通過 CPS-inversion-style 抽象概念進行線程錯誤，譬如異步保證，其他一些我們希望能夠提供合適語言支持的東西。一般來說，expressing effects 作為一元值是一個相當糟糕的抽象；除了通過沒完沒了的無用教程污染互聯網環境，他們也不做清潔，而是強加在想要的地方 - 你不得不在
Result<Async<T>>和Async<Result<T>>抉擇，亦或是為ResultT<AsyncT<Identity>><T>建立一個單子轉換器 - 同時當和其他高階的抽象一起使用時，它們不做自然的事情 - 倘若你正在映射一個throws函數到一個集合中，你可能更傾向于通過rethrows來進行錯誤拋出，而不是以Result<T>集合告終。我寧愿看到我們采用一個可擴展的代數效應系統，譬如 http://www.eff-lang.org 為throws、aync和其他一些控制流效應提供了框架，以達到干凈地組合和抽象的目的。我認為throws將作為第一個“種子”。
當然總是有那么幾個原型 Result 庫不能使你滿意。
Joe Groff 恢復了早前關于編譯器指令的話題，同時 Erica Sadun 為此起草了一份新提案，旨在為模擬器和設備目標擴展構建配置測試。“該提案新增#if target(simulator) 和 #if target(device)用于區分應用代碼是否運行在模擬器上，亦或是真機設備上。”
寫在最后
最后 —— 還在為使用面向協議編程猶豫不覺？何不嘗試下 面向 side-effect 編程，前提是必須使用值類型。一旦進行了值拷貝，就不再是你的問題嘍。??
