我們期待的 Swift 3.0 將會是什么樣？

類型化的錯誤

我第一個期望就是類型化的錯誤(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 團隊正面臨的實際問題和長期目標而言是非常的幼稚的，因為整個社區都知道他們所做的一切棒極了！