【译】回顾Swift 3, 展望Swift 4

原文: Looking back on Swift 3 and ahead to Swift 4
做者: Chris Lattner
译者: kemchenj

你们好，

Swift 3的正式版已经接近完成状态了, 是时候来回顾一下发布以前的事情, 从中汲取经验, 而且用来整理一下咱们(Swift社区)在今年作的事情了. 总的来讲, Swift 3无疑将会是一个Amazing的版本, 咱们作到的很了不得, 谢谢每个为这件事情贡献力量的人. 比起立刻推动那一堆新计划, 更重要的是让咱们每一个人从整个大局来看, 了解本身作到的这些了不得的事情.

Metapoint: 这份邮件很长并且覆盖了不少主题, 比起直接回复, 最好仍是从新开一个对话来对单独的一个话题进行讨论, 在主题上标上[Swift 4]就行了.

Swift 3回顾

每一年Swift的开发都会跟前一个版本彻底不一样, 我预计Swift 4也会延续这个习俗, 为了每年都要有所收获有所提高, 我总结了一下这些关于Swift 3开发过程当中的观察和回顾:

• 开源万岁. 看到这么一个有活力的社区合做得这么好真的是让人以为很难以想象, 并且看到大家一晚上之间几乎都过来帮忙了. 能和这样一个才能和热情兼顾的团队一块儿工做真是一件很是棒的事情.

• 开源一样也带来了一些挑战. 我以为Open Design确实仍是比Closed Design进展得更加慢并且更加不可预计. 然而, 最后的结果也是比Open Design明显更胜一筹, 权衡之下仍是很值得的. 全部在Swift Evolution进展过程里帮助过咱们的人, 送给大家一个大大的感谢...

• 软件项目管理(特别是开源项目)一如既往的难以预料. 咱们给Swift 3设定了一系列太高的目标, 以致于最后不得不删减掉一部分, 目标定得高是一件好事, 但咱们须要更好地告诉你们这些"目标"并非"承诺", 以避免你们感到失望.

• 对少数几个主题的专一. 若是有太多的主题同时推动, 那就没人能持续跟进全部主题了. 核心团队有必要在一些关键的讨论里及时介入. 在Swift 3的开发流程里, 很大的一个问题是, 不少的fork在审核结束以前都没有时间去跟进全部的讨论.

• 拥有清晰地目标是一种解放. 特别是在十二月和一月份这一段时间里, 咱们把目标定为适合Swift 3的那些Proposal, 而且同时开展了好几个计划, 结果咱们发现这已经大大超出咱们能完成的范围了. 在后来的版本里, 咱们有很是明确的目标(例如, 再也不增长计划), 从而让咱们节约更多精力去专一在那些重要的事情里.

• 让全部人的满意是不可能的. 特别是在讨论要选哪些Feature和定优先级的时候, 由于有些明显是低优先级的事情. 这是必然的, 由于不可能让全部有趣的东西在一年的开发里都塞进一个版本里. 所幸, 总会有另外一个版本, 每个新的版本都会成为一次大改进的其中一小步.

以此为背景, 让咱们继续说下去!

Swift版本计划

下一年, 核心团队预计能够完成两个Swift的大版本: 2017年春季推出Swift 3.x, 还有同年秋季发布的Swift 4. 除了大版本以外, 咱们也保证会更新一些小版本(例如 Swift 3.0.1)来修复bugs, 或者是核心库须要的服务, 或者其余Swift.org的计划.

Swift 4版本规划

从Swift 3的经验来看, 咱们知道咱们必须有所选择. 对于Swift 4来讲, 一个主要的目标就是保持Swift 3.0到4.0的代码稳定(API稳定), 而且把标准库的ABI稳定下来. 由此, 核心团队决定把开发计划分为两个阶段:

第一阶段:

专一代码稳定和ABI稳定的工做, 对于这份工做保持合理的专一. 这意味着任何不会从根本上更改现有Feature的ABI, 或者对于标准库不会有破坏性的修改在这个阶段都不会考虑(就是说这个阶段要进行的修改都是破坏性的). 例如, 泛型功能里的Condition Confomance是一个附加功能, 但由于它的增长会对标准库产生不少影响, 因此这就会是第一阶段的任务. 另外一方面, 语法方面的支持对于现有ABI或者标准库都不会有大改变, 因此不太适合在第一阶段完成.

第一阶段的工做很重要(下文有更多细节), 因此咱们春季以前都会比较忙碌.

第二阶段:

设计和实现会在第一阶段完成的七七八八, 咱们会根据剩余的时间去完成一些比较大型的feature, 我以为咱们应该能有时间去推动下边表里的一部分Feature, 不过获得咱们了解具体剩余的时间才能知道是哪一部分.

除了新Feature以外, 咱们也须要从新评估一下那些咱们已经接受了的, 会对代码有破坏性, 但还没加入到Swift 3里的提案. 这些提案不必必定要定下来, 咱们须要考虑Swift 4的目标, 根据每一个提案的具体状况进行评估.

最后, 这跟Swift-Evolution没有特别的关系, 只是我我的想要质量和性能兼备, 核心团队想要继续提升质量, 包括修复bugs和提升error和warning的算法. 性能优化也是咱们开发中一直在作的事情, 包括提升代码质量, 提升标准库的实现, 加快编译速度等等. 全部这些工做均可以同时进行.

Swift 4第一阶段目标

为了专一于代码和ABI稳定, 核心团队对于第一阶段的规划有一个初步的讨论. 这几个Feature是咱们在第一阶段定为最优先的:

• 代码稳定: 这件事情虽然很小, 但很重要. 例如, 咱们须要在编译的时候加上-std=swift3之类的命令. 咱们也提供了一个途径去提供一个不稳定的开发环境, 以便咱们更容易去测试.

• 适应性'Resilience': 这个Feature提供了一个方法可以在ABI稳定的状况下, 让Public API可以持续演变. 例如, 咱们不想要C++里Fragile Base-Class的问题发生在Swift里. 不少设计和实现都已经在Swift 3里完成了, 但还有一些关键的部分还没完成, 包括用户在模型里能看到那些(例如新的属性).

• ABI细节处理: 在现代的代码模型里, 还有一大堆细节须要咱们去认真评估和优化. 这跟Swift的开发关联比较大, 而不仅是Swift-Evolution的话题.

• 泛型的提升: 我但愿Conditional Conformances可以排在这个列表的最前面, 还有协议递归约束(Recursive Protocol Requirements)以及更多强力的相关类型约束. 然而, 绝对有必要去消除掉剩下的那些 "_" 协议还有以正确的方式长期呈现. (However, the standard library gurus need to break down what is absolutely essential to finally eliminate the rest of the “_” protocols and manifest the public API of the standard library in the right way for the long term.)

• 新的字符串API范式: 字符串是一门语言里其中一个重要的基础类型. 标准库的主导团队有不少提升编程范式和想法, 并且不会跟Unicode-correct-by-default的范式冲突. 咱们的目标是在字符串处理上比Perl作的更好.

• 内存全部权Memory Ownership Model: 在Swift添加相似于Cyclone/Rust的那种内存全部权机制, 在系统编程人员和但愿获取到可预计可控制(例如, 实时音频处理)的人里呼声很大. 跟Swift 4更相关的是, 这个Feature的重要性在于它会从根本上改变ABI. 它解释了编译的时候inout是如何处理的, addressors在ABI里处于哪一层抽象, 影响Swift的运行时, 还会对类型系统和Name Mangling产生巨大的影响.(It informs code generation for “inout", how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.)

这里面每个部分咱们都有一些想法了, 但距离一份完整的提案还有很长的一段的路. 我预计, 也但愿这些想法能今早进入Swift 4的主要讨论里. 甚至, 咱们尚未完整的了解这些将会如何影响ABI稳定, 随着咱们的了解加深也许会有更多其它具体的影响. 最后, 咱们也许会专一于某个会可以对Swift包管理器或者其它Swift.org计划具备不少价值的Feature.

Swift 4第二阶段 可能的努力方向

就像我前面提到的, 在这个时间点咱们是不可能知道第二阶段的时候咱们的进度, 由于咱们并不知道这段时间会有多长. 为了可以在正式版来临以前修复更多bug, 以及让这一个版本的生命周期变得更长, 核心团队更倾向于在Swift 4开发的时候延续Swift 3的开发周期.

因此说, 我以为咱们应该可以完成至关一部分新Feature, 我对这件事情很乐观. 给你一些它们的概要, 我整理了一份列表, 但记住, 这不是一份计划或者承诺, 这只是一份广泛要求的feature的列表:

• 反射Reflection: 核心团队承诺过要一些强力的动态feature. 例如Swift 3已经完成了数据反射data reflection的基础建设(已经用在了Xcode的内存分析). 咱们应该利用这些基础设置去构建一个强大的面向用户的API. 一样的, 咱们也想要设计和构建动态函数反射的runtime以及API的支持.

• First class concurrency: Actors, async/await, atomicity, memory model和相关的话题. 你们对于这个feature有很强烈的需求, 由于它会引入全部客户端, 服务端以及其它更多方面的新东西. 咱们计划在第二阶段开始正式讨论这个, 但很明显一个新的并发模型不会在Swift 4的开发周期里作出来, 道理很简单, 由于这件事情须要花费超过一年的时间去设计和实现, 并且咱们但愿用足够的时间去把这件事情作对作好. 在这件事情完成以前, Memory Ownership Model更容易理解(It also makes sense for the memory ownership model to be better understood before taking this on).

• 泛型加强: 泛型计划包含了许多使人兴奋的泛型系统的改进, 里面不少都对于标准库ABI稳定没有要求, 但这会让Swift的泛型更增强力和易于表达.

• Swift模块稳定: 某程度上说咱们须要.swiftmodule二进制库稳定下来, 以便第三方库的使用(或者使用另外一种机制). 这里面有不少工做须要完成, 而且须要标准库的ABI稳定.

• 新的文本feature: 常规的书写方式, 多行字符串字面值链接multi-line string literals之类的. 有这些功能会让Swift更加吸引那些须要文本处理和使用web技术的人. 这也会帮助完成字符串的模型.

• Property behaviors: 这个feature能够在现有的Property模型里提供更增强大的抽象. 被推迟的SE-0030计划阐释的很清楚.

• 其余的还有许多, Submodules, implicit promotions between numeric types, 导入C++的API, hygenic macro system, 尾调用约定(guaranteed tail calls), 可遍历的枚举, thows类型, 自定义属性User defined attributes, 抽象函数/类abstract methods/classes, 更好的SIMD支持, dynamic for non- at objc(目前的dynamic自己是基于objc的runtime), data parallelism, higher kinded types, ...

• 语法糖: 我不会把这些所有列出来, 可是老是有不少别的零零碎碎的Proposal提交上来, 特别是那些别的语言用来解决特定问题的方案. 这在Swift 4里优先级别最低.

就这样, 一份很长的邮件, 包含了一些咱们关于明年要作的事情的想法. 还有一件特别的事情就是我知道Swift 3还没完成. 当破坏性的修改完成以后, 还须要时间去修复bug和其余一些优化, 这些都很重要.

我以为如今花点时间来讨论一下咱们明年的开发计划仍是颇有帮助的, 而后把第一阶段的feature的概念所有理顺, 咱们只应该去写那些容易理解的特殊设计. 看到一大堆提案在那里摆着, 而后没有足够的时间去跟进它们, 核心团队不想陷入这样的境地, 咱们只想处理那些摆在咱们面前, 大型的, 重要的, 优先级高的计划.

Thank you. 再强调一次, 若是你想要深刻探讨某个话题的话请从新开一个分支.

-Chris