回顾Swift 3展望Swift 4

本文来自Swift作者克里斯-拉特纳，小波翻译加调侃

小伙伴们好

Swift 3发布即将临近之际，是时候回顾此间种种来展望Swift社区的前路。这么来总结，Swift 3这次正式版绝对是“屌爆了”，“谁在装B好刺眼”的大新闻。感谢所有小伙伴们！面对无数大跨步的提案，我们守住当下所成，从而才能着眼更大的目标。

Swift 3 回顾 

每年Swift开发都跟上年完全不一样（简直无情），我期待Swift 4能延续这一趋势（心好累）。在逐年的更新和改善这一根本宗旨下，我想Swift 3有以下一些回首和展望之处：

-开源是王道！Swift社区活力四射，团结一致，不舍昼夜；与这样一群有才有激情的小伙伴一起玩耍，那画面简直太美太梦幻（基情洋溢，羞耻play）

-开源也是挑战。“开放式设计”可能确实比“封闭式设计”要慢要更不可估，可结果确实不一般的好，值了。在Swift进化过程中，我要给所有帮忙的朋友给一个大大的“赞”。

-具体实现的计划日期（部分因为开源的关系）仍然是难以测算。我们给Swift 3设定的宏大目标不得不部分延期。有远大目标固然好，但“目标”不等于“承诺”，希望我们能更好地沟通而不误导大家。

-整个社区因为专注有限个主题的实现而顺利向前推进，因为如果啥都做可能就翻车了。保持核心团队只在关键点上的讨论非常重要。Swift 3整个过程中，很多分支代码直到审核完成我们都来不及关注确实烦恼。

-目标清晰是一种解放。尤其是今年12月到明年1月的时间段，我们扩展了要塞进Swift 3里面新想法的范围，还搞了一些目前还谈不上能完成的工程。这次正式发布以后，我们有一些特定的目标（比如“非附加性提案”）让大家能更容易关注在更重要的目标上。

-无法让所有人满意。尤其是讨论新特性的优先级-因为这样无形降低了其他东西的优先级。这是不可避免的，因为没办法在一年的更新周期中把这些有意思的工作完成。还好，总有“下一个正式版”（套路好深，心太累），新版本总有大的改进。

话不多说，计划如下！

Swift发布计划

2017年核心团队计划发布2个主要版本：Swift 3.x(春)和Swift 4（秋）。除此之外还会发布一些小版本（如Swift 3.0.1）包含修复bug或corelibs的改进或Swift.org上的其他工程。

即将的Swift 4 发布周期

有Swift 3的经验伴身，取舍之道我们了然于心。Swift 4主要目标是实现从3.0开始的源码稳定性这项承诺（终于不再大改语法了，泪奔），并且提供标准库的ABI稳定性。因此核心团队决定来年分2步走：

阶段一:

关注源码和ABI稳定性的核心需求，而且是很严格限制在这两点。因此任何不是颠覆标准库ABI特性或ABI大幅变更的特性均不被考虑此阶段之内。

比如，泛型特性像是“条件遵从”是个附加特性，但此项是让标准库更犀利，会是第一阶段要实现的。另一方面，语言层面对正则表达式的支持，因不影响既有ABI也不对既有标准库特性产生大的变更，所以不在这一阶段内。

这些目标限定在阶段一而且关系重大（下面有详细阐述），我们估计要忙一整个冬天了。

阶段二：

随着第一阶段工作中的设计和实现的全部完成，我们圈定少数还未完成的重要特性，这个计划基于我们余多少时间。对于下面一个长长的待实现特性列表，我还是持乐观预期。不过（话不能说太满）这取决于最终知道完成这些东西所需时间。

除了新特性以外，我们也需要重评估Swift 3中没有实现的源码级变更的提案。这些提案不一定会被重提-将之与Swift 4目标进行对比，逐个来确定。

最后，一些不是特别和Swift进化相关的话题，我想归之为“品质与性能”。核心团队致力于持续提升品质，包括修复编译器bug和提升错误提示和警告信息的诊断信息可读性。性能也是关键开发中持续改进的一个领域，包含通用代码的性能提示，标准库实现的提升，编译时间加速等。这些工作在两个阶段都有。

### Swift 4 阶段一目标 ###

因为有了关注源码和ABI稳定性这个目标，核心团队对此阶段实现内容初步讨论了一次。以下是我们优先要实现的特性：

– 源码稳定性: 这些相对优先级低一点，但很重要。比如，我们需要一个”-std=swift3″之类的编译器标记（flag）。可能还要加一种方式，用来条件性启用开发中但还处于稳定期的新特性，以便易于试用。

– 弹性: 提供一种使用不断更新的公有API的机制，即便面临ABI稳定性的问题。比如，我们不想C++的“脆弱基类”问题在Swift中出现。虽然大多数设计和实现将在Swift 3的阶段完成，但仍有数个缺失之处，包括model的用户可见性（比如 新属性）。

– ABI 细节: 这里多如牛毛的细节需要仔细审查及提升代码生成模型。这里大部分与“swift开发”相关，不是一个很“swift进化”的话题。

– 标准库所需的泛型类型的改进:

-我期待“条件遵从”成为头个优先项，和递归协议约束及更强大的关联类型约束的实现。不过，标准库的权威就要被打破，即最终清除所有残余的”_”协议类型的绝对必要性，以显示标准库的公共API未来一直在正确路线上。

– 字符串重评估：字符串是语言中一个极其重要的基础类型。标准库的大佬们有大量对编程模型的改进建议，同时不影响提供一个基于unicode默认模型的字符串的目标。我们的目标是（没有蛀牙）-比Perl的字符串处理更强！

– 内存拥有者模型: 添加一个（可选的）Cyclone/Rust启发式内存拥有者模型到Swift中，是系统开发者急切需求的，此功能用以实现可预测和可确定的性能指标（比如在实时音频处理代码中）。Swift 4很多特性与此相关，因此非常重要因为它可以根本性改善ABI。它通知“inout”这样的高级代码，（ABI中的）用低级别的“addressor”如何运作的。不仅影响Swift运行时，而且会对类型系统和命名粉碎系统（name mangling）产生重大影响。

以上每一个领域都已实现了一部分，不过成为正式提案还有很长的路要走。我期待能在Swift 4周期的早期阶段能列为主要讨论对象。还有，因为我们还没有完成确定影响ABI稳定性的范围，可能还有其他特定的额外部分需要学习。最后，我们可能会缩小范围，尤其对SwiftPM（Swift包管理器）或其他Swift.org项目有高价值的特定小特性。

### 可能的 Swift 4 阶段 2 努力目标 ###

就像我上面提到的，在这个点是没办法知道确切的阶段2时间表的，因为我们不知道时间表到底是多久。核心团队也想尽早比Swift 3同期更早地开始这一阶段的开发，如此便能在发布前修复更多bug和提供更多测试时间。

也就是说，对我们有能力重拾和处理一些已经是嗷嗷待哺的痛点。为了让你有个初步印象，这里列了一下。请注意这个表不是已确定的计划和义务，只是一些待实现的常规特性：

– 反射（Reflection）: 核心团队致力于给Swift添加强大的动态特性。比如，Swift 3已经给数据反射添加了几乎所有所需的基础设施（Xcode内存调试器已经在使用）。我们可以用这些基础设施构建强大的面向用户API。类似地，我们也想设计和实现出动态方法反射运行时及相关API支持。

– 语言级的并发:

Actor, async/await, 原子性, 内存模型和相关话题.

这个领域已经是刚性需求，同时可以打开通向c/s架构之类新玩意的大门。我们计划在阶段二中开启正式“讨论”，但可惜能确定的是，这个新并发模型不会在Swift 4正式版中完成。原因非常简单，这个东西的设计和实现已经超过12个月（的版本周期）了，而且我们想花时间把它做做好。在开始之前，更好地把内存拥有者模型理解也是有用的。

– 泛型改进: 泛型主题包含很多对泛型系统令人激动的改进，其中不少并不会需要标准库的ABI稳定性，但能让Swift泛型更强大和炫酷。

– .swiftmodule 稳定性: 在某个时间点上需要稳定“.swiftmodule”二进制文件格式（或者用一个不同的机制替换）从而允许第三方二进制框架。这其中需要海量工作而且基于标准库的ABI稳定性。

– 新脚本特性: 正则表达式，多行字符串等。这些特性会让对熟悉脚本处理和web技术的人群更有吸引力。也有助于完善字符串（String）模型。

– 属性行为: 此项特性承诺提供对已有出现模型更强大的抽象化。延期的SE-0030提案中有详细的描述。

– 杂项: 子模块、数字类型的隐式提升、C++ API导入、简洁的宏系统、保证的尾部调用、枚举数字化、类型化的’throws’，用户定义属性，抽象方法/类，更好的SIMD支持、非objc的‘动态化’，数据并行支持，高阶类型,…

– 语法糖： 我不会全列出来了，但经常有多如牛毛的琐碎的小提案冒出来，通常这些东西在其他语言中解决特定的问题。这些对于Swift 4来说是低优先级。（其他语言的粉丝表示心碎）

至此，我这封啰嗦的邮件列出对于我们明年要做的事情的一些想法。有一点要指出的是，Swift 3还没最终完成。此时代码（相对于Swift 2.2）的大幅变更已经（接近）完成，但仍需时间修复bug和品质化工作，这对发布至关重要。

如何处理来年的版本发布，现在立即讨论这些相关的基本要求，我认为是很有用的，以便能在第一阶段能概念性的落实这些特性。我们应该只开始撰写那些能充分理解的设计。Swift核心团队“不想”陷入无数满天飞却抓不住的提案的境地，这是重大、高优先级的工程的拦路虎。

再次感谢！如果你想就特定主题深入请多开新帖。

-Chris

转自：http://www.xiaoboswift.com/archives/126