Swift 3.0：你的代码即将崩坏

资讯频道 → 编程语言

0顶
0踩

2016-03-23 08:41 by 副主编 mengyidan1988 评论(0) 有5394人浏览

Swift

当我们提到代码崩坏（code breaking）时，一般是指下面这两种情况。

语音语义发生了变化。这时你需要重构代码，典型例子就是 Swift 从 (…, $NSError) -> Result? 格式改为错误抛出。
语言语法发生了变化。这时只需进行迁移，然后大部分代码或多或少都能自动修复（还有一小部分需要微调）。

后者确实会带来一些麻烦，但更具破坏性的是前者。如果我猜的没错，Swift 3 的目标是进行最后一次内部调整，等到 Swift 4 时就不会再重新设计语言了，而是增加新的特性。

Chris Lattener 写道：

引用

赞同 —— Swift 3 的源码调整已经完成了，所以我们会提供非常棒的迁移工具，帮助人们能够迅速完成迁移工作。除了 Swift 3 外，Swift 社区将会成为多元化社区，支持多个平台系统，创造出更多不同的工具和 IDE 供开发者使用。

正因如此，在 Swift 3 发布之后，源码崩坏修复（source breaking changes）会更加困难，我们倾向于尽可能地把改动放到 Swift 3 中。

更多内容：

引用

虽然 Swift 4 可能也有一些崩坏改动，不过我们更希望能够减少崩坏的情况。

时间框架：

引用

这也是为什么我们要努力完善 Swift 3 的原因，在目前的时间限制下，即使这意味着要推掉一些有趣的工作……

……

我认为现在没有必要讨论 Swift 3 之后的特性，也不会带来什么好处。没有足够的资源让核心团队成员参与讨论，我们更希望能够让社区和开源贡献者将主要的精力集中在 Swift 3 上，力争让 Swift 3 功能更加强悍。

Swift 3 的特性能够预示 Swift 4 的走向。尽管有一些特性我们能够预知（例如并发会成为 Swift 的一个特性），仍然有很多完全不同的设计方向值得我们探讨和尝试。虽然现在不太可能来一场讨论，权衡决定哪种是最好的解决方案，不过大量的讨论必定会浪费时间。

现在需要所有相关的人等到合适的时间再来讨论，虽然这需要足够的耐心和克制，不过对每个人来说，这是最好的。今年秋天（北半球）很快就要到了，我们还有太多重要的工作需要完成。

将 Swift 3 的各种目标固定下来列出时间表这件事shanks