我们期待的 Swift 3.0 将会是什么样？
Sash Zats
Labgoo 、 Wondermall 的 iOS 工程师、用户体验设计师及 API 架构师
类型化的错误
我第一个期望就是类型化的错误(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 团队正面临的实际问题和长期目标而言是非常的幼稚的，因为整个社区都知道他们所做的一切棒极了！
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
