回顾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