我們期待的 Swift 3.0 將會(huì)是什么樣？ —— 此調(diào)查來(lái)自官方的 Swift 社區(qū)

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

Sash Zats  

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

類(lèi)型化的錯(cuò)誤

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

依賴(lài)類(lèi)型

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

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

Cocoa 的 Swift 分支

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

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

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

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

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

Jorge Ortiz

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

更好的輔助工具

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

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

完善的測(cè)試

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

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

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

Sam Giddins

UChicago 2018. CocoaPods. Bundler.

高階泛型類(lèi)型

首先我需要向大家道個(gè)歉，因?yàn)槟憧赡軙?huì)很反感我們這些驕傲的開(kāi)發(fā)者需要向 Swift 團(tuán)隊(duì)乞求我們所希望的 Swift 3 新特性。不過(guò)我覺(jué)得實(shí)現(xiàn)這個(gè)特性是最為重要的，因此無(wú)論怎樣我都在所不辭。

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

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

Jacob Schwartz

Glint 首席工程師

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

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

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

所以不要讓我們難以取舍，讓我們?cè)谌魏螘r(shí)候都能夠用上最新的語(yǔ)言！

Viktor Belenyesi

Prezi 首席 iOS/Mac 開(kāi)發(fā)者

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

就像 Scala 的特性一樣，如果我們能夠給既有類(lèi)中通過(guò)擴(kuò)展添加新的存儲(chǔ)屬性的話，這將會(huì)是巨大的改進(jìn)。我們可以用 ObjC 運(yùn)行時(shí)來(lái)實(shí)現(xiàn)此功能，但是這種代碼給我的感覺(jué)很不好，因?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 開(kāi)發(fā)者

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

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

Sam Ritchie

CodeSplice首席Codesplicer

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

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

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

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

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

Tony Arnold

Itty Bitty Apps 以及 The CocoaBots 的首席開(kāi)發(fā)者

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

同樣我希望在明確需要使用 Optional.None 的地方讓nil被禁用掉，不過(guò)這聽(tīng)起來(lái)像是我喝多了才會(huì)提出這個(gè)建議的。

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

Benji Encz

Make School 工程師，即將入職 PlanGrid

類(lèi)型化的錯(cuò)誤處理

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

那么，你期望中的 Swift 3.0 是什么樣子的呢？

轉(zhuǎn)載自 realm.io