Chris Lattner 对 Swift 3 的总结与对 Swift 4 的展望

作者：Erica Sadun，原文链接，原文日期：2016-07-29
译者：wiilen；校对：saitjr；定稿：CMB

Chris Lattner 写了一篇文章：回顾 Swift 3，展望 Switf 4，以下是这篇文章的关键内容：

• 开源大有益处，但无法让所有人满意。

• Swift 3 将在 2016 年秋到来。Swift 3.x 会在 2017 年春公布，Swift 4 会在 2017 年秋发布，这其中不包括修复 bug、提升兼容性之类的小更新（例如 3.0.1）。

• Swift 4 在交付时一定会保障代码的稳定性，增加容错性、ABI，优化泛型与字符串等等。

• 语法糖的优先级最低，没有提上日程。

• 安排进度有些困难。开发的目标并非是对交付的保证。从一开始安排计划与进度就是最主要的事。

下面是全文：

---

大家好呀，

Swift 3 的正式版已经基本完成，是时候让我们回顾一下这个版本了，从开发过程中汲取经验，并用于总结我们（Swift 社区）在这一年内所做的事。总体上来说，Swift 3 毫无疑问将是一个 amazing 的版本，我们完成了很多出色的工作。感谢所有为它付出的人。相比于立刻着手推进新计划，盘点过去、展望未来同样重要。

提示：这封 email 长得吓人，其中涵盖了各方面的话题。比起直接回复，更好的选择是开一个新话题来讨论。只需在主题上标记“［Swift 4］”即可。

Swift 3 回顾

每年 Swift 的新版本都与前一年完全不同，我希望 Swift 4 能继续保留这个传统。为了每一年都有提升与进步，以下是一些对 Swift 3 的回顾与建议：

• 开源有许多好处。见证一个充满活力的团队合作得如此之好，大家几乎彻夜为其付出，让人不可思议、充满惊喜。与这样一个才华横溢并充满热情的团队合作，实在是太棒了！

• 开源也带来挑战。比起“闭源设计”，“开源设计” 进度更慢且更加不可预料，我想这么说应该是公允的。然而，开源的结果明显更好，因此权衡之下开源是值得的。“感谢你们”，献给所有帮助 Swift 发展进化的人。

• 预估 软件开发的进度（特别是开源项目）依然困难到近乎不可能。我们在着手开发 Swift 3 的时候设立了许多高目标，在后期不得不进行修整。设立一些高目标是好事，但我们需要在沟通上更努力，让其他人知道“目标”不等于“承诺”，避免误导他们。

• 整个社区得益于在有限的主题上保持专注，因为如果有太多事项同时进行，没有人可以持续跟进所有部分。参与到前面所提的关键讨论中，对核心团队而言非常重要。在 Swift 3 的开发周期中，很多人在代码评审结束前都没有时间来跟进讨论，这是一个问题。

• 确立清晰的目标是一种解脱。特别是在去年十二月到今年一月，我们大致圈出了那些适合放入 Swift 3 的点子，同时开启了几个项目，这些项目最后远超出我们的能力范围。在后来的版本中，我们确立了几个具体目标（比如“不再加入新计划”），使所有人能更轻松地关注重要事项。

• 皆大欢喜是不可能的，尤其是在我们讨论优先开发哪些功能时，因为这会降低其他一些功能的优先级。这是一个无解的局面，因为我们并没有办法将所有有意思的工作都放在一个只有一年长的开发周期中。幸运的是，将来“总会有下一个版本”，每一个新版本都会加入一些重大的改进。

在上述回顾的基础上，我们来展望未来！

Swift 发布计划

在接下来一年里，核心团队预计会发布两个主要的版本：2017 年春发布 Swift 3.x，2017 年秋发布 Swift 4。除了主要版本之外，我们也会发布一些小的更新（如 Swift 3.0.1）来修复 Bug，或满足核心库的需求，或其他的 swift.org 的项目。

Swift 4 发布计划

从我们在 Swift 3 中获得的经验来看，我们需要挑出一些重点。对 Swift 4 来说，主要目标是从 3.0 开始要保证交付的代码的稳定性，并为标准库提供 ABI 的稳定性。因此，核心团队决定在接下来的一年中实施两个阶段的计划：

第一阶段：专注于提升代码及 ABI 稳定性，全心投入只完成这项必要的工作。这意味着如果一些功能不会从根本上改变现有语言特性的 ABI ，或是对标准库的 ABI 进行了破坏性的改动，那么现阶段都不会考虑开发它们。举个例子，泛型中的条件一致性（Conditional conformances）是一个附加特性，但由于它会对标准库造成众多更改，我们在第一阶段就要实现它。另一方面，正则表达式不会对现有 ABI 造成影响，也不会给标准库带来大量改动，所以第一阶段不会考虑它。

第一阶段的工作非常重要（下面会详细介绍），所以春季之前我们大概一直会很忙。

第二阶段：当第一阶段功能的设计与实现工作较好得完成之后，我们将基于剩余时间，选择一些大型的功能进行开发。我乐观估计将有剩余时间，来从长长的功能列表中选几个来开发，但具体选哪几个，得看最后剩多少时间。

除了新功能之外，我们也需要重新评估那些在 Swift 3 中尚未实现的、对代码造成破坏性变动的提案。这些提案不一定会被通过，我们需要在 Swift 4 的基础上来评估它们，挨个决定如何处理。

最后，虽然与 Swift 的进步没有特别大的关系，但我想提一提质量与性能问题。核心团队想要进一步提升质量，包括修复编译器的 Bug、改进错误与警告检测功能。性能是开发中另一个需要重视的部分，包括提升编译后的代码质量，改善标准库的实现，加快编译速度等。这些工作在任何开发阶段都需要重视。

Swift 4 第一阶段目标

为了专注于代码与 ABI 的稳定性，核心团队对第一阶段的工作有一个初步的讨论。下面是我们对第一阶段功能排序后的结果：

• 代码稳定性相关功能：这一部分工作量相对较小，但很重要。举个例子，我们需要类似于“-std=swift3”的编译器标志。我们也需要一个新方法来开启一些大型的功能，这些功能尚在开发，并不稳定，有了这个方法，调试会更简单。

• 适应力（Resilience）：这个功能提供了一种方式，在保证 ABI 稳定性同时，公有 API 可以随时间改进。一个例子，我们不想让 C++ 的“fragile base class” 问题发生在 Swift 中。更多设计与实现上的工作已经在 Swift 3 中完成了，但仍有重要工作未完成，包括模型中用户可见的部分（例如新的属性）。

• ABI 细节：代码生成模型中仍有大量细节需要审核与改进。这一部分与 Swift 开发更相关，与 Swift 的演进关系不大。

• 泛型改进需要在标准库的基础上进行：我希望条件一致性能在功能清单中处在最高位置，递归协议要求（recursive protocol requirements）与更强大的关联类型约束能处在随后的相近位置。然而，标准库的开发者们需要大量时间来解析出至关重要的部分，最终消除那些“_”协议，并正确展现标准库中的公有 API。

• 字符串相关改进：字符串是 Swift 中最重要的基本类型之一。标准库的开发者有很多点子，能改进它的编程范式而不影响到提供 unicode-correct-by-default 范式。我们的目标是在字符串处理上比 Perl 做得更好！

• 内存所有权模型（Memory ownership model）：许多系统开发者，以及想要可预测及确定性的性能（如在实时音频处理中）的人们，都非常希望 Swift 中能有一个（可选的）类似于 Cyclone / Rust 的内存所有权模型。从 Swift 4 的目标上来说，这个功能很重要，因为它从根本上改变了 ABI。这一模型会通知编译器“inout”事件的产生，解释底层“addressors”如何在 ABI 中运作，影响 Swift runtime，并对类型系统及命名管理产生显著影响。

我们对上面这些功能都有了一些想法，但它们在正式成为提案之前仍有很长路要走。我期待它们会在 Swift 4 的早期成为主要讨论内容。不仅如此，由于我们还没有全部找出那些影响 ABI 稳定性的部分，可能还有其他需要增加的条件。最后，我们也可能选择其他一些对 SwiftPM 这个包管理器，或其他对 swift.org 有高价值的小功能。

可能的 Swift 4 第二阶段工作

如我之前所提到的，在这个点上不可能知道还有多少时间留给第二阶段，因此也不知道第二阶段能完成哪些工作。核心团队也希望比 Swift 3 更早完成 Swift 4 开发版的合流，以便在版本发布之前有更多时间修复 BUG，仔细斟酌。

也就是说，我乐观估计我们能够挑一些大家都想要的新功能来开发。为了让你对这些功能有个概念，我列了张表。请注意这并不是开发的计划或承诺，而只是列了一些大家都希望有的功能：

• 反射：核心团队正致力于为 Swift 添加强大的动态机制。举个例子，Swift 3 中大致完成了数据反射的基础结构（已被用在 Xcode 的 memory debugger 中）。我们应在这些基础结构之上，搭建一些强大的面向用户的 API。同样，我们想要设计并实现动态方法反射的 runtime 与 API 支持。

• 最重要的并发：Actors、异步 / 等待（async / await）、atomicity、内存模型（memory model）以及相关话题。这些是大家都想要的，因为有了它们，就可以在客户端、服务端等之上开发更多新功能。我们计划在第二阶段正式讨论这件事，但非常明确地告诉大家，新的并发模型在 Swift 4 发布时还无法完成。我们需要超过一年的时间来进行设计与开发，我们也希望把这件事做好做对。需要这么多时间，也是因为在开发内存所有权模型之前能更深入的理解它。

• 泛型改进：泛型的开发计划中包含来许多激动人心的功能，能改进现有泛型系统。在提升标准库的 ABI 稳定性时并不需要这些功能，但它们会使 Swift 的泛型更加强大易懂。

• .swiftmodule 的稳定性：在某些方面我们需要使“.swiftmodule”的二进制文件格式稳定下来（或用不同的机制替代它），允许开发第三方的二进制框架。这个工作量很大，并需要标准库 ABI 保持稳定。

• 新的脚本功能：包括正则表达式、多行字符串字面量等。有了这些功能，Swift 在密集型文本处理任务及搭建 web 等方面会更有吸引力。这些功能也有助于完善字符串模型。

• 属性行为：这一功能承诺为现有属性模型提供强大的抽象能力。在被推迟的 SE-0030 提案中对它有完整描述。

• 其他功能：子模块、数值类型间的隐式转换、导入 C++ API、hygenic macro system、尾调用约定、枚举类型遍历、带类型的“thorws”、用户定义属性、抽象方法 / 类、更好的 SIMD 支持、非 @objc 的动态支持、支持数据并行、更高等级的类型...

• 语法糖：我不会把它们全部列出来，但有大量零散的小提案会经常出现，特别是那些其他语言中出现过、用于解决特定问题的。这些在 Swift 4 开发中都属于最低优先级。

好了，这是一封超长的邮件，列出了一些关于明年要做的事的想法与点子。有一点要提醒一下大家，目前 Swift 3 尚未完成。当对代码的破坏性改动（将要）完成时，需要留有一些时间来修复 Bug 并提升代码质量，这对于正式发布版很重要。

我认为如果我们马上花一些时间来讨论明年开发计划的一些基本事项，会很有帮助，然后再从概念上分解一些第一阶段的特性。只有在对它们有深入了解之后，我们才应该开始写一些提案。核心团队不希望被太多提案淹没，以至于无法跟踪它们的进展，或让我们无法专注于那些高优先级的项目中。

谢谢大家。再次提醒一下，如果大家想要更深入讨论某个话题，请重新开一个分支。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 http://swift.gg。