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。