[[155457]]

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

Sash Zats

Labgoo、Wondermall 的 iOS 工程師、用戶體驗(yàn)設(shè)計師及 API 架構(gòu)師

類型化的錯誤

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

依賴類型

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

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

Cocoa 的 Swift 分支

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

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

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

雖然這不大可能會發(fā)生，因?yàn)檫@種變化需要一個獨(dú)立的團(tuán)隊(duì)為現(xiàn)有和新的 API 建立一個全新的版本，這個過程中需要耗費(fèi)極大的努力。

我知道，我的這些想法和 Swift 團(tuán)隊(duì)正面臨的實(shí)際問題和長期目標(biāo)而言是非常的幼稚的，因?yàn)檎麄€社區(qū)都知道他們所做的一切棒極了！

Jorge Ortiz

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

更好的輔助工具

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

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

完善的測試

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

內(nèi)省機(jī)制

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

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

高階泛型類型

首先我需要向大家道個歉，因?yàn)槟憧赡軙芊锤形覀冞@些驕傲的開發(fā)者需要向 Swift 團(tuán)隊(duì)乞求我們所希望的 Swift 3 新特性。不過我覺得實(shí)現(xiàn)這個特性是最為重要的，因此無論怎樣我都在所不辭。

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

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

Jacob Schwartz

Glint ***工程師

取消 Xcode 和 Swift 版本的關(guān)聯(lián)

我很高興能夠看到 Swift 語言演變至今，我認(rèn)為它的團(tuán)隊(duì)正在做一個十分了不起的工作，并且他們能預(yù)測到我們的需要，并且對大眾反饋?zhàn)龀龇磻?yīng)。

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

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

Viktor Belenyesi

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

擴(kuò)展中的存儲屬性

就像 Scala 的特性一樣，如果我們能夠給既有類中通過擴(kuò)展添加新的存儲屬性的話，這將會是巨大的改進(jìn)。我們可以用 ObjC 運(yùn)行時來實(shí)現(xiàn)此功能，但是這種代碼給我的感覺很不好，因?yàn)槲颐看味急仨気斎脒@樣的鬼東西：

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ā)者

自定義泛型類型中的協(xié)變機(jī)制

Swift 中內(nèi)置的類型已經(jīng)是協(xié)變(covariant)的了，但是當(dāng)涉及到自己創(chuàng)建的 Party 的時候，一般情況下就必須要給來賓名單中加入不同的人，不然的話這個設(shè)計就是失敗的。

Sam Ritchie

CodeSplice***Codesplicer

約束泛型的協(xié)議一致性

Swift 擴(kuò)展有兩個非常有用的功能，一個是能夠增加協(xié)議的一致性(protocol conformance)，比如說在 Swift 1 中：

? 
extension String: JSONEncodable { 
func toJSON() -> JSON { return .String(self) 
}} 

另一個就是能夠給協(xié)議增加泛型約束(generic constraints)，比如說在 Swift 2 中：

extension Array where Element: JSONEncodable { 
func toJSON() -> JSON { 
return .Array(self.map { $0.toJSON() }) 
} 
} 

很遺憾的是，你不能將這兩者結(jié)合起來（即給約束泛型類型添加協(xié)議一致性），比如說：extension Array: JSONEncodable where Element: JSONEncodable 這種寫法是無法通過編譯的。這意味著如果你在嘗試使用“面向協(xié)議編程”的話，你不僅需要避免使用泛型，還要花費(fèi)大量的時間和精力來寫重載函數(shù)。如果這項(xiàng)特性能夠在 Swift 3 中實(shí)現(xiàn)的話，那么我相信它能拯救很多代碼，讓協(xié)議以及泛型更加有用。

Itty Bitty Apps 以及 The CocoaBots 的***開發(fā)者

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

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

說句實(shí)話，我并沒有實(shí)實(shí)在在地思考過 Swift 3.0 的模樣。標(biāo)準(zhǔn)庫就已經(jīng)很好很簡潔了，如果它缺少什么東西的話，你實(shí)際上可以自己搭建出來。

Benji Encz

Make School 工程師，即將入職 PlanGrid

類型化的錯誤處理

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