转载

我们期待的 Swift 3.0 将会是什么样?

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

正文到此结束
Loading...