2023 年 Swift 项目进展

2022 年 11 月 18 日

John McCall

Swift 项目正在进行许多令人兴奋的工作，由于这些工作发生在许多不同的代码仓库、pull request 和论坛帖子中，因此很难跟踪所有进展。为了让社区更好地了解全局，核心团队调查了项目中的各个工作组和开发者，收集了他们在接下来一年中的工作重点信息。

请记住，这里的所有内容都不能保证会包含在项目的任何特定版本中——计划和优先级会随着时间推移而变化。 这也不是项目中正在发生的所有事情的详尽列表。 但是我们希望您觉得这些内容有趣且信息丰富，如果您对其中任何领域有疑问，请随时联系并询问更多详情。

社区组织

长期以来，Swift 拥有相当中心化的结构，核心团队直接监督项目的许多不同领域。

核心团队最近开始重组，以便更多责任由专门的工作组承担

• 语言工作组—— 发展语言和标准库
• 网站工作组—— 管理 swift.org 上的 Web 内容
• 文档工作组—— 组织文档工具和库的开发
• C++ 互操作性工作组—— 孵化改进 C++ 互操作性的语言提案

这些新的工作组加入了长期存在的 Swift on Server 和 多元化 工作组，并使人们更容易通过加入致力于其兴趣的工作组来做出贡献。

核心团队正在研究创建更多的工作组，包括一个致力于提高 Swift 在跨平台上的可用性的工作组。

核心团队更新

Mishal Shah 将加入核心团队。作为 Swift 项目许多底层基础设施的领导者和倡导者，在相当长一段时间内，Mishal 在支持 Swift 项目的发展方面发挥了至关重要的作用。

语言开发

语言工作组致力于在五个主要的语言领域取得进展

1. 并发。 完成对 Sendable 和 actors 提供的严格数据隔离的语言支持。 这包括弥补许多已知的线程安全漏洞，例如围绕全局变量和某些跨 actor 调用的漏洞。 它还包括可能添加语言特性来解决严格隔离带来的一些可用性问题，例如允许非 Sendable 值在受限情况下在隔离域之间移动。

2. 泛型。 开始认真研究可变泛型语言特性。 这是一个预计需要多年才能完成的主要特性。 最初的重点是设计核心语言模型，并实现支持它的基本编译器和运行时基础设施。 一个早期的里程碑将是允许元组类型在它们的元素符合协议（如 Equatable）时有条件地遵循这些协议。

3. 所有权.

   • 开发特性以使程序员能够显式控制内存中值的所有权。 这包括禁止隐式复制、在上下文之间转移所有权以及显式“借用”值而不复制它们的功能。

   • 添加对不可复制类型的基本支持。 这将提供通过限制关键值的生命周期来实现高性能的新方法。 这些控制将提供使用内存中数据的新方法，将当前“不安全”构造的性能与 Swift 标准库特性的安全性相结合。

4. 宏。 开发过程宏的基础知识，以进一步增强富库和 DSL 的创建。 这项工作将从创建愿景文档开始，以阐述宏在 Swift 中可以实现的目标以及它们如何融入语言。

5. C++ 互操作性.

   • 编写文档，阐述如何使 C++ API 可从 Swift 使用以及反之亦然的设计愿景。

   • 稳定当前已原型化的互操作性特性，以便从 Swift 中使用 C++，其中包括拥有的值类型、平凡的值类型、API 模式（例如外部引用类型和迭代器）以及围绕方法、指针以及左值和右值引用的一些基本问题。

   • 稳定当前已原型化的互操作性特性，以便从 C++ 中使用 Swift，包括 Swift 值类型、引用类型和函数如何暴露给 C++。

由此工作产生的任何语言更改都将按照 Swift 演进流程 进行提案和审查。

语言工作组还致力于改进和澄清演进流程，并将发布管理提案时使用的流程的详细文档，以及提案作者和审阅者的指南。

最后，语言工作组计划最终确定即将到来的 Swift 6 语言模式的预期语言更改。 Swift 定期引入新的语言模式，以便语言可以进步，而不会破坏现有代码的源代码兼容性。

构建系统集成和改进

编译器开发团队正在努力改进编译器与构建系统以及自身其他调用的交互方式

• 允许构建系统更深入地与 Swift 编译器集成，使它们在如何构建 Swift 程序方面具有更大的灵活性，并使构建更健壮。 这项工作包括将 Swift 编译器转向显式模块加载，并将模块依赖项的发现和编译分离到单独的编译器调用中。 它还包括添加发现模块链接时依赖项的能力，允许构建系统直接调用链接器本身，而不是要求通过 Swift 编译器调用链接器。

• 提高自动生成的 Swift 文本接口和二进制模块基础设施的质量，以帮助库作者更可靠和高效地发布他们的 Swift API。 相关的诊断信息也将被添加，以培养良好的工程实践。

• 开发支持灵活软件集成的功能，允许不同团队以不同节奏开发的软件组件在编译时和运行时都能平滑地集成。

软件包注册表

Swift 软件包管理器的开发重点是与社区合作，开始开发开源软件包注册表服务器实现。 目标是创建将 Swift 软件包生态系统从基于源代码控制过渡到基于注册表所需的技术组件，从而增强生态系统的安全性和可靠性。 我们将与社区运营的项目（例如 Swift Package Index）合作，以确保在注册表带来的好处之外，还能实现出色的软件包发现功能。

实现改进

编译器开发者专注于实现层面的几项改进

• 开发一个纯 Swift 编写且功能完备的 Swift 解析器，与当前的 C++ 实现功能对等。 这为工具开发开辟了新的方向，并将最终取代 C++ 解析器。

• 通过将类型推断实现迁移到更可扩展的基础架构（支持多语句闭包推断），提高 result builder 的类型检查性能。

• 通过与类型检查器更紧密地集成，提高代码补全和查找依赖工具（如 Quick Help 和跳转到定义）的可靠性，尤其是在不完整或有歧义的代码中。

• 通过在某些情况下消除对转换 thunk 的需求来减少转换函数时生成的代码，尤其是在将闭包传递给泛型函数和导入函数时。

• 通过解释类型布局的紧凑编码而不是发出专门的函数，来减少复制和销毁复杂结构体和枚举时生成的代码。

• 添加 SIL 优化器对新语言功能和与对象生命周期和副本相关的可预测优化的支持。 正在设计一套新的底层 SIL 实用程序，以在整个现有优化管道中维护所有权不变性。 这将产生可靠的诊断和可预测的性能。

• 用 Swift 重写当前的过程间副作用和转义分析，替换当前的 C++ 实现。 新的实现提供了更准确的结果，并且明显更简单。

文档工作组

新成立的文档工作组很高兴推动 Swift 生态系统中更好的文档体验。 在接下来的一年中，工作组将改进工具以满足文档需求，并指导为 Swift 项目文档做出贡献的新努力。

为了鼓励 Swift 生态系统中更多更好的文档，工作组的举措将是双重的

1. 简化使用 Swift-DocC 开始编写和发布文档的流程。 一个目标是使开发人员无需配置额外的插件即可生成文档。

2. 扩展 Swift-DocC 的范围以支持多目标项目配置和长篇散文内容。 对于由多个库组成的软件包，支持为整个软件包而不是其每个单独的库发布文档。

工作组还将支持新开源的 “The Swift Programming Language” 书籍的开发，目标是用新仓库的内容替换现有的发布管道。 这项工作将包括定义为 Swift 语言编写优秀文档的指南，以及为 Swift 生态系统定义文档指南的长期目标，类似于 API 命名指南。

网站工作组

新成立的网站工作组 专注于从多个方面增强 swift.org 网站

• 改进网站访问量最高的页面上的内容，包括 主页、入门指南 和 下载页面。 重要的是，这些页面要直观易用，并包含实现该目标所需的恰当信息。 工作组还希望提高文档的可发现性，这是网站访问者经常寻求的另一个领域。

• 迭代布局设计和导航。 工作组计划推出视觉设计系统的基础，该系统可以帮助社区在特定领域（例如 Swift on Server 指南）做出贡献。

• 鼓励更广泛的 Swift 社区参与 swift.org 的发展，使其更容易为网站和 Swift 文档做出贡献。

• 鼓励发布社区驱动的博客文章，简化流程并阐明此类文章的指南。

• 继续探索基于 Swift 的技术来生成网站。

Swift on Server 工作组

Swift on Server 工作组继续专注于推进 Swift 在服务器和 Linux 上的状态，与社区合作创建高质量的库和工具，并提高在行业中的知名度。 工作组专注于以下几个领域

• 推动在服务器生态系统中全面采用 Swift 并发模型，采用 async/await API 作为面向用户 API 的标准。

• 促进更高级别服务器端功能的标准化，包括跟踪、中间件、HTTP 通用类型和基本路由/HTTP 服务器类型。

• 提高对如何使用 SwiftPM 插件来推进服务器用例工具状态的认识，包括部署到云平台。

• 提高工具链、库和工具在 Swift 项目官方支持的所有平台上的覆盖率和一致性。

• 扩展 swift.org 上提供的以服务器为中心的指南。

• 推进 Swift 在流行的行业工具中的支持，例如 Dependabot、GitHub Security Advisory DB 等。

可微 Swift

在支持 AI/ML 应用方面，可微 Swift 的工作仍在继续，重点关注多项改进

• 通过修复可微 Swift 中遇到的影响生产应用程序的问题来提高稳健性。随着时间的推移，观察到的这类问题越来越少，但问题跟踪器中仍然存在一些已知问题（许多问题都有简单的重现方法）。

• 显著提高使用可微 Swift 编译的代码的性能。一个例子是编译器生成的 Swift 函数的“反向传递”。原则上，执行此传递应该与函数的原始（“正向”）版本一样快。目前，在许多情况下，反向传递的速度要慢几个数量级；未来一年计划进行一些优化，应该会使反向传递的速度快得多。

• 实现 KeyPath 的性能改进。虽然关键路径严格来说不是可微 Swift 的一部分，但在优化用于内省的强类型模型时，关键路径变得极其重要。第一步是努力向编译器套件添加一套稳健的关键路径基准。

参与其中

如果您有兴趣参与其中，有很多方法可以做到。

语言更改会经历演变过程，因此请密切关注您感兴趣的工作的讨论主题、提案和提案审查。

如果您对这篇文章中的任何项目有疑问或反馈，请联系相应的工作组或在与这篇文章关联的论坛帖子上提问。