给每一个 Swift 版本设定开发主题

作者：Ole Begemann，原文链接，原文日期：2017-03-20
译者：四娘；校对：Cwift；定稿：CMB

大概一个星期之前，Swift 核心团队成员 Ben Cohen 在 Swift-Evolution 发了一条的很值得思考的信息，回答了一个问题 — 再给 Swift 4 提一个新提案, 被通过的几率有多大。

Ben 阐述了核心团队决定提案是否要推迟的主要依据。主旨就是 Swift 每一个版本都应该专注于一小部分主题，符合主题的提案给予更高的优先级。

我认为 这篇文章 并没有引起足够的重视，这也是为什么我把它完全引用过来的原因(链接和注解是我自己加的)：

Swift 4 的主题设定好之后，一些不符合主题的提案还是进入了我们的讨论，这显得一点意义也没有。例如一些关于 String ， Dictionary 和 Sequence / Collection 的提案被采纳。在 Swift 接下来的版本里，很可能这些与目标不符合的提案，例如 String 进一步的完善(原生的正则表达式)，move-only 类型，异步，反射，或者是泛型的加强，都会进入讨论。我们觉得专注于特定的主题对于一门语言的演变特别重要，这些散乱的，与当前开发主题无关的提案，应该要设置更高的采纳门槛。

其中一个原因是核心团队和社区的精力有限。专注一部分目标进行讨论，可以让别的社区更容易参与到我们的讨论里(尽管加入提案模板也会有帮助)。而且如果保证每一个提案都能够为这个阶段的目标服务，我们就可以避免一些提案虽然被采纳，但从未有机会实现的情况出现。

此外，专注于某个目标进行讨论时，针对这个目标，我们可以有完成度更高，更加具有一致性的功能设计。可以探讨如何在 Swift 4 里把所有新的泛型功能合理地组合到一起，构建一个完善，高度一致的体系，让我们更容易使用和理解。或者是新的字符串功能如何更加便捷地处理字符串。一方面是向大家传递 Swift 4 想要完成的目标，一方面更利于我们去完成一个条理清晰，连贯的设计。

一个条理清晰的设计不止对于版本的迭代很重要 — 因为这可以让开发者更容易学习使用新功能，而且对于语言的长期发展也是一样重要。没有明确目标的提案，会让我们非常难理解单个提案怎么融入到 Swift 整体的发展方向里。我们想要避免进行了一些局部的改进过后，后续再次触及相关的部分时，却发现当时的改进并不符合整体设计。同时还有一种情况是，我们考虑了太多分开看起来很合理的功能，但将它们拼凑到一起时却并不合适。

例如，最近的一些提案围绕着重构 meta types ，但这必须在反射这个大框架下讨论才可以，所以我们应该等到这个主题被提上议程再去讨论。另外一个例子: 最近的提案 SE-154 提议可以自定义存储字典键值对的集合，这种做法并没有降低耦合度，它只是提供了一种略微笨重的方式去解决问题 — 给字典提供一个初始值，然后去更新这个值。但它需要作为ABI 稳定的一部分去思考。这也是我们决定在 第二阶段 展开关于字典的讨论的原因。

对于 Swift 3 和 Swift 4 ，核心团队给每一个版本都设定了主题。核心团队想要在这个过程中，让社区更早加入到讨论中，帮助核心团队决定接下来的目标，但也会同时思考更好的方式。

Swift 4.0 的开发周期已经过半，但还不能太早决定接下来 Swift 5 的目标。 ABI 稳定 肯定优先，但除此之外呢？字符串再进一步的改进？异步？反射?

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