Swift社區調查：我們期待的 Swift 3.0 將會是什么樣？
隨著諸如協議擴展、錯誤處理等 Swift 2.0 新引入的強大特性發布，這都意味著蘋果已經明確表示，它們非常積極地聽取來自開發者社區的意見來幫助完善和改進這門語言。我們調查了幾位使用 Swift 的開發者朋友，詢問他們對下一個版本的 Swift 有何希冀，因此他們將在類型系統、協議以及工具等方面和我們一起分享他們的想法。
Sash Zats
Labgoo、Wondermall 的 iOS 工程師、用戶體驗設計師及 API 架構師
類型化的錯誤
我***個期望就是類型化的錯誤(typed error)，雖然這個想法還很不成熟，但是卻能給錯誤處理帶來極大地改善。Swift 2 引入了新的錯誤處理機制，但是遺憾的是，和語言中其他結構不同，錯誤結構并不是類型安全的。這樣做的好處就是錯誤處理成為了函數簽名(function signature)的一部分，比如說 do something() 和 do something() throws 的類型并不相同，前者無法代替后者來使用；壞處就是 dosomething() throws 無法指明它能夠拋出的錯誤類型（就像協議列表一樣：throws<IOTypes, NetworkingError>）。
依賴類型
我的第二個期望是提供“依賴類型”(dependent type)的支持。這個想法同樣仍未完全在我的腦海中成型，不過我確信它將給現有的類型系統中帶來全新的絕妙體驗！它將給值類型本身加入限制，類型系統的解析方式為：未定類型的數組 -> 字符串數組 -> 只含有2個元素的字符串數組。這對現有語言來說是一個極其有用的補充。下面的例子闡述了這個功能在什么地方比較有用：
- class Car {
- var wheels: [Wheel]<4> = [Wheel(), Wheel()]
- // 編譯錯誤，類型不匹配，需要 4 個Wheel 類型
- }
Cocoa 的 Swift 分支
***，我希望看到（不過很可能不會實現）Cocoa 的 Swift 分支版本。雖然 Cocoa 是一個很棒的框架集合，但是它自身攜帶的內容實在過于龐大，有可能會影響到 Swift 的開發方式。
我很想看到無需進行引用的結構體能夠普遍應用到新的分支上來（在我的想象中，我認為諸如 UIBarButtonItem、UINavigationItem 之類的類應該不需要讓你來累積它們的狀態，因此它們可以被替換為結構體）。因此，我們就可以重新設計 API，盡可能地使用枚舉中關聯值的優勢。在某些情況下，枚舉能夠更精確地描述其作用：例如 UIDatePicker 可以在一個屬性中使用關聯枚舉，來同時表示其日期值和創建值所使用的模式。
- class UIDatePicker {
- enum Value {
- case Date(date: NSDate)
- case CountDownTimer(period: NSTimeInterval)
- }
- var value: Value?
- }
雖然這不大可能會發生，因為這種變化需要一個獨立的團隊為現有和新的 API 建立一個全新的版本，這個過程中需要耗費極大的努力。
我知道，我的這些想法和 Swift 團隊正面臨的實際問題和長期目標而言是非常的幼稚的，因為整個社區都知道他們所做的一切棒極了！
Jorge Ortiz
PoWWaU 創始人，移動開發開發者及教師
更好的輔助工具
我希望有一套比較成熟的輔助工具。比如說，我希望有一個我可以永遠信賴的調試器，而不是時不時出錯的玩意兒。這個調試器能夠在當前的堆棧幀顯示某個 符號的實際值。此外，我還希望有一個能夠對 Swift 進行重構的編輯器，就像在 Objective-C 中所做的那樣，這樣我就可以在它的幫助下改善我的代碼，比如說將一些語句提取到方法中，或者重命名項目中某個類或方法的名稱。
這個編輯器需要能夠生成代碼，將我從代碼套路中拯救出來（我的意思不是指代碼片段）。例如，如果編譯器發現我的類或者結構沒有完全實現某個協議，那么我希望有一個選項能夠讓編輯器自動將定義中所缺少的方法創建出來。
完善的測試
第二個愿望非常簡單，但是卻能夠讓進行測試的人們感到由衷的高興。我希望運行測試時無需使用模擬器，這樣能夠提升使用體驗。如果某個類只基于 Foundation，那么對其的測試應該可以無需模擬器就可以進行。這將減少需要運行的測試套件，使測試花費的時間更短。
內省機制
第三個愿望就涉及到語言本身了。我希望 Swift 擁有更好的內省(Introspection)能力，如果你愿意的話也可以稱之為反射(reflection)。此外，還希望其擁有更加動態化的調度機 制。沒有了這些特性，諸如 Mocking 框架之類的工具將無法被創建出來。
Sam Giddins
UChicago 2018. CocoaPods. Bundler.
高階泛型類型
首先我需要向大家道個歉，因為你可能會很反感我們這些驕傲的開發者需要向 Swift 團隊乞求我們所希望的 Swift 3 新特性。不過我覺得實現這個特性是最為重要的，因此無論怎樣我都在所不辭。
由于高階泛型類型(High-Kinded Type)是一個難以理解的東西，因此我打算用我們最喜歡的函數式編程比喻——卷餅，來為大家解釋。我們知道，我們可以用同樣的方式吃各種各樣的卷餅，無 論里面的內容如何，因為卷餅本身只是內部填充物的一個包裝而已。但是，如果我們有這樣一個方法告訴 Swift，“這里是一個對象，我唯一關心的事情只是它是一個卷餅，無論里面卷了牛排還是蔬菜還是蝦，我都只關心它是一個卷餅。”然而 Swift 并不能讓你輕易做到，如果你要吃某個卷餅的話，你首先需要這么做：“擁有相同填充物的卷餅是相同的”。這樣的話，你會發現你能使用的卷餅為數甚少……
我們勉為其難地說目前 Swift 的上層結構類型并不能讓我們這樣表示。并沒有任何辦法寫出關于 Monad 或者 Functor 的定義，這些定義可以用在該類型的所有實例當中，舉個例子，這意味著我們所添加的每個全新的 SequenceType，都必須表示為 S: Equatable when S.Element: Equatable 的形式。這讓代碼重復量十分可怕，這意味著我們不能將我們的真實目的編碼到類型系統中，導致我們程序員有更多犯錯和制造 bug 的情況發生。
Jacob Schwartz
Glint ***工程師
取消 Xcode 和 Swift 版本的關聯
我很高興能夠看到 Swift 語言演變至今，我認為它的團隊正在做一個十分了不起的工作，并且他們能預測到我們的需要，并且對大眾反饋做出反應。
對于 Swift 3.0 來說，我很希望能夠從不同版本的 Xcode 中使用這門語言。我并沒能夠完全深入地研究 Swift 2.0，因為它只能夠在 Xcode 7上面使用，而 Xcode 7 取消了支持 iOS7 。將 Xcode（以及 iOS SDK）和 Swift 版本關聯起來會造成不必要的惰性，阻礙開發者們遷移到新的語法當中。
所以不要讓我們難以取舍，讓我們在任何時候都能夠用上***的語言！
Viktor Belenyesi
Prezi *** iOS/Mac 開發者
擴展中的存儲屬性
就像 Scala 的特性一樣，如果我們能夠給既有類中通過擴展添加新的存儲屬性的話，這將會是巨大的改進。我們可以用 ObjC 運行時來實現此功能，但是這種代碼給我的感覺很不好，因為我每次都必須輸入這樣的鬼東西：
- extension UIView {
- var myTag: String? {
- get {
- return objc_getAssociatedObject(self, "myTag") as? String
- }
- set(newValue) {
- objc_setAssociatedObject(self, "myTag", newValue, UInt(OBJC_ASSOCIATION_RETAIN))
- }
- }
- }
- Agnes Vasarhelyi
Prezi iOS/Mac 開發者
自定義泛型類型中的協變機制
Swift 中內置的類型已經是協變(covariant)的了，但是當涉及到自己創建的 Party 的時候，一般情況下就必須要給來賓名單中加入不同的人，不然的話這個設計就是失敗的。
Sam Ritchie
CodeSplice***Codesplicer
約束泛型的協議一致性
Swift 擴展有兩個非常有用的功能，一個是能夠增加協議的一致性(protocol conformance)，比如說在 Swift 1 中：
- ?
- extension String: JSONEncodable {
- func toJSON() -> JSON { return .String(self)
- }}
另一個就是能夠給協議增加泛型約束(generic constraints)，比如說在 Swift 2 中：
- extension Array where Element: JSONEncodable {
- func toJSON() -> JSON {
- return .Array(self.map { $0.toJSON() })
- }
- }
很遺憾的是，你不能將這兩者結合起來（即給約束泛型類型添加協議一致性），比如說：extension Array: JSONEncodable where Element: JSONEncodable 這種寫法是無法通過編譯的。這意味著如果你在嘗試使用“面向協議編程”的話，你不僅需要避免使用泛型，還要花費大量的時間和精力來寫重載函數。如果這項特性能夠在 Swift 3 中實現的話，那么我相信它能拯救很多代碼，讓協議以及泛型更加有用。
Itty Bitty Apps 以及 The CocoaBots 的***開發者
我對語言本身其實沒有太大的期望，不過如果能有類似 C# 之類的語言的異步風格函數(Async-Style Function)的話，那就再好不過了。不過我最想看到的還是更好的輔助工具。在 Xcode 中使用 Swift 仍然是一件很痛苦的事情，比如說我無法使用重構，這讓我感覺好像在使用幾十年前的 IDE一般。如果能有更好的工具，并且有更清晰的錯誤提示的話，那無疑再好不過了。
同樣我希望在明確需要使用 Optional.None 的地方讓nil被禁用掉，不過這聽起來像是我喝多了才會提出這個建議的。
說句實話，我并沒有實實在在地思考過 Swift 3.0 的模樣。標準庫就已經很好很簡潔了，如果它缺少什么東西的話，你實際上可以自己搭建出來。
Benji Encz
Make School 工程師，即將入職 PlanGrid
類型化的錯誤處理
我最想看到的就是函數可以拋出他們能夠產生的錯誤類型。目前蘋果的建議是在函數的文檔中寫出這些錯誤類型，但是如果編譯器也知曉這些錯誤類型的話那是不是 更好一些呢？這樣就可以實現一個精確的錯誤處理，而不是使用一個 catch-all 的錯誤捕獲。這同樣可以讓 API 中可產生錯誤的函數能更好地表述自己。
