[[155457]]

隨著諸如協議擴展、錯誤處理等 Swift 2.0 新引入的強大特性發(fā)布，這都意味著蘋果已經明確表示，它們非常積極地聽取來自開發(fā)者社區(qū)的意見來幫助完善和改進這門語言。我們調查了幾位使用 Swift 的開發(fā)者朋友，詢問他們對下一個版本的 Swift 有何希冀，因此他們將在類型系統(tǒng)、協議以及工具等方面和我們一起分享他們的想法。

Sash Zats

Labgoo、Wondermall 的 iOS 工程師、用戶體驗設計師及 API 架構師

類型化的錯誤

我***個期望就是類型化的錯誤(typed error)，雖然這個想法還很不成熟，但是卻能給錯誤處理帶來極大地改善。Swift 2 引入了新的錯誤處理機制，但是遺憾的是，和語言中其他結構不同，錯誤結構并不是類型安全的。這樣做的好處就是錯誤處理成為了函數簽名(function signature)的一部分，比如說 do something() 和 do something() throws 的類型并不相同，前者無法代替后者來使用；壞處就是 dosomething() throws 無法指明它能夠拋出的錯誤類型（就像協議列表一樣：throws<IOTypes, NetworkingError>）。

依賴類型

我的第二個期望是提供“依賴類型”(dependent type)的支持。這個想法同樣仍未完全在我的腦海中成型，不過我確信它將給現有的類型系統(tǒng)中帶來全新的絕妙體驗！它將給值類型本身加入限制，類型系統(tǒng)的解析方式為：未定類型的數組 -> 字符串數組 -> 只含有2個元素的字符串數組。這對現有語言來說是一個極其有用的補充。下面的例子闡述了這個功能在什么地方比較有用：

class Car { 
var wheels: [Wheel]<4> = [Wheel(), Wheel()] 
// 編譯錯誤，類型不匹配，需要 4 個Wheel 類型 
} 

Cocoa 的 Swift 分支

***，我希望看到（不過很可能不會實現）Cocoa 的 Swift 分支版本。雖然 Cocoa 是一個很棒的框架集合，但是它自身攜帶的內容實在過于龐大，有可能會影響到 Swift 的開發(fā)方式。

我很想看到無需進行引用的結構體能夠普遍應用到新的分支上來（在我的想象中，我認為諸如 UIBarButtonItem、UINavigationItem 之類的類應該不需要讓你來累積它們的狀態(tài)，因此它們可以被替換為結構體）。因此，我們就可以重新設計 API，盡可能地使用枚舉中關聯值的優(yōu)勢。在某些情況下，枚舉能夠更精確地描述其作用：例如 UIDatePicker 可以在一個屬性中使用關聯枚舉，來同時表示其日期值和創(chuàng)建值所使用的模式。

class UIDatePicker { 
enum Value { 
case Date(date: NSDate) 
case CountDownTimer(period: NSTimeInterval) 
} 
var value: Value? 
} 

雖然這不大可能會發(fā)生，因為這種變化需要一個獨立的團隊為現有和新的 API 建立一個全新的版本，這個過程中需要耗費極大的努力。

我知道，我的這些想法和 Swift 團隊正面臨的實際問題和長期目標而言是非常的幼稚的，因為整個社區(qū)都知道他們所做的一切棒極了！

Jorge Ortiz

PoWWaU 創(chuàng)始人，移動開發(fā)開發(fā)者及教師

更好的輔助工具

我希望有一套比較成熟的輔助工具。比如說，我希望有一個我可以永遠信賴的調試器，而不是時不時出錯的玩意兒。這個調試器能夠在當前的堆棧幀顯示某個 符號的實際值。此外，我還希望有一個能夠對 Swift 進行重構的編輯器，就像在 Objective-C 中所做的那樣，這樣我就可以在它的幫助下改善我的代碼，比如說將一些語句提取到方法中，或者重命名項目中某個類或方法的名稱。

這個編輯器需要能夠生成代碼，將我從代碼套路中拯救出來（我的意思不是指代碼片段）。例如，如果編譯器發(fā)現我的類或者結構沒有完全實現某個協議，那么我希望有一個選項能夠讓編輯器自動將定義中所缺少的方法創(chuàng)建出來。

完善的測試

第二個愿望非常簡單，但是卻能夠讓進行測試的人們感到由衷的高興。我希望運行測試時無需使用模擬器，這樣能夠提升使用體驗。如果某個類只基于 Foundation，那么對其的測試應該可以無需模擬器就可以進行。這將減少需要運行的測試套件，使測試花費的時間更短。

內省機制

第三個愿望就涉及到語言本身了。我希望 Swift 擁有更好的內省(Introspection)能力，如果你愿意的話也可以稱之為反射(reflection)。此外，還希望其擁有更加動態(tài)化的調度機 制。沒有了這些特性，諸如 Mocking 框架之類的工具將無法被創(chuàng)建出來。

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

高階泛型類型

首先我需要向大家道個歉，因為你可能會很反感我們這些驕傲的開發(fā)者需要向 Swift 團隊乞求我們所希望的 Swift 3 新特性。不過我覺得實現這個特性是最為重要的，因此無論怎樣我都在所不辭。

由于高階泛型類型(High-Kinded Type)是一個難以理解的東西，因此我打算用我們最喜歡的函數式編程比喻——卷餅，來為大家解釋。我們知道，我們可以用同樣的方式吃各種各樣的卷餅，無 論里面的內容如何，因為卷餅本身只是內部填充物的一個包裝而已。但是，如果我們有這樣一個方法告訴 Swift，“這里是一個對象，我唯一關心的事情只是它是一個卷餅，無論里面卷了牛排還是蔬菜還是蝦，我都只關心它是一個卷餅。”然而 Swift 并不能讓你輕易做到，如果你要吃某個卷餅的話，你首先需要這么做：“擁有相同填充物的卷餅是相同的”。這樣的話，你會發(fā)現你能使用的卷餅為數甚少……

我們勉為其難地說目前 Swift 的上層結構類型并不能讓我們這樣表示。并沒有任何辦法寫出關于 Monad 或者 Functor 的定義，這些定義可以用在該類型的所有實例當中，舉個例子，這意味著我們所添加的每個全新的 SequenceType，都必須表示為 S: Equatable when S.Element: Equatable 的形式。這讓代碼重復量十分可怕，這意味著我們不能將我們的真實目的編碼到類型系統(tǒng)中，導致我們程序員有更多犯錯和制造 bug 的情況發(fā)生。

Jacob Schwartz

Glint ***工程師

取消 Xcode 和 Swift 版本的關聯

我很高興能夠看到 Swift 語言演變至今，我認為它的團隊正在做一個十分了不起的工作，并且他們能預測到我們的需要，并且對大眾反饋做出反應。

對于 Swift 3.0 來說，我很希望能夠從不同版本的 Xcode 中使用這門語言。我并沒能夠完全深入地研究 Swift 2.0，因為它只能夠在 Xcode 7上面使用，而 Xcode 7 取消了支持 iOS7 。將 Xcode（以及 iOS SDK）和 Swift 版本關聯起來會造成不必要的惰性，阻礙開發(fā)者們遷移到新的語法當中。

所以不要讓我們難以取舍，讓我們在任何時候都能夠用上***的語言！

Viktor Belenyesi

Prezi *** iOS/Mac 開發(fā)者

擴展中的存儲屬性

就像 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 開發(fā)者

自定義泛型類型中的協變機制

Swift 中內置的類型已經是協變(covariant)的了，但是當涉及到自己創(chuàng)建的 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 的***開發(fā)者

我對語言本身其實沒有太大的期望，不過如果能有類似 C# 之類的語言的異步風格函數(Async-Style Function)的話，那就再好不過了。不過我最想看到的還是更好的輔助工具。在 Xcode 中使用 Swift 仍然是一件很痛苦的事情，比如說我無法使用重構，這讓我感覺好像在使用幾十年前的 IDE一般。如果能有更好的工具，并且有更清晰的錯誤提示的話，那無疑再好不過了。

同樣我希望在明確需要使用 Optional.None 的地方讓nil被禁用掉，不過這聽起來像是我喝多了才會提出這個建議的。

說句實話，我并沒有實實在在地思考過 Swift 3.0 的模樣。標準庫就已經很好很簡潔了，如果它缺少什么東西的話，你實際上可以自己搭建出來。

Benji Encz

Make School 工程師，即將入職 PlanGrid

類型化的錯誤處理

我最想看到的就是函數可以拋出他們能夠產生的錯誤類型。目前蘋果的建議是在函數的文檔中寫出這些錯誤類型，但是如果編譯器也知曉這些錯誤類型的話那是不是 更好一些呢？這樣就可以實現一個精確的錯誤處理，而不是使用一個 catch-all 的錯誤捕獲。這同樣可以讓 API 中可產生錯誤的函數能更好地表述自己。