我们期待的 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 团队正面临的实际问题和长期目标而言是非常的幼稚的，因为整个社区都知道他们所做的一切棒极了！