原文: 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支持,dynamicfor non- at objc(目前的dynamic本身是基于objc的runtime), data parallelism, higher kinded types, ...语法糖: 我不会把这些全部列出来, 但是总是有很多别的零零碎碎的Proposal提交上来, 特别是那些别的语言用来解决特定问题的方案. 这在Swift 4里优先级别最低.
就这样, 一份很长的邮件, 包含了一些我们关于明年要做的事情的想法. 还有一件特别的事情就是我知道Swift 3还没完成. 当破坏性的修改完成之后, 还需要时间去修复bug和其他一些优化, 这些都很重要.
我觉得现在花点时间来讨论一下我们明年的开发计划还是很有帮助的, 然后把第一阶段的feature的概念全部理顺, 我们只应该去写那些容易理解的特殊设计. 看到一大堆提案在那里摆着, 然后没有足够的时间去跟进它们, 核心团队不想陷入这样的境地, 我们只想处理那些摆在我们面前, 大型的, 重要的, 优先级高的计划.
Thank you. 再强调一次, 如果你想要深入探讨某个话题的话请重新开一个分支.
-Chris