Swift 周报第五期

周报仓库：https://github.com/SwiftCommunityRes

前言

Apple 举办了 Unleashed 活动发布了新品，借助超强的 M1 Pro 或 M1 Max 芯片，不管是基于新款的 MacBook Pro 开发应用，还是开发 MacBook Pro 下的应用，新机都将给我们带来突破性的性能和惊人的电池使用时长。

再加上强大的神经引擎，用于增强机器学习和升级的支持 ProRes 的媒体引擎，新款 MacBook Pro 能让我们的 App 做前所未有的事情。

为了 Swift 社区周报持续稳定的发布更新，我们希望邀请 Swift 爱好者参与周报编辑，同时邀请赞助商对我们平台赞助支持。

入门任务

SR-15312 [Swift-DocC] 添加 “version” 命令到 docc 命令行工具中

SR-15312 [Swift-DocC] 当浏览器 URL 不是小写时，主教程导航下拉菜单无法将当前教程字体加粗

新闻和社区

Franklin Schrans 宣布 Swift-DocC 将要开源.

Marin Todorov 终于披露了他关于 Swift Markdown 的工作.

Federico Zanetello 写了一篇文章来说明 @warn_unqualified_access 的使用.

Dave DeLong 解释了如何简化 Swift 中的向后兼容性。

Swift-DocC 的文档现在已经发布在 Swift.org (使用 Swift-DocC!).

正在审查的提案

SE-0325 附加包插件 API 正在审查中。

SE-0303 在 SwiftPM 中引入了定义构建工具插件的能力, 允许自定义工具在构建打包时被调用。为了支持该特性， SE-0303 引入了最小初始 API，插件能够通过该接口获取那些被唤起构建的 Target 的相关信息。

该提案扩展了插件 API 以提供更多上下文，包括更丰富的包图表示。这是为将来支持新类型的插件做准备。

Swift 论坛

1. Nuri Amari 提出了改进 ClangImporter 的建议。

提出对 ClangImporter 的改进建议，当导入 C 或 Objective-C 实体发生错误时提供更详细的反馈。就目前而言，当 ClangImporter 无法完全或部分导入实体（函数、类型、宏等）时，出现错误是不会提示的。当前的 Swift 编译错误大部分情况下会提示从未定义过实体。

2. Frederick Kellison-Linn 提出了关键路径到函数转换的想法。

该提案介绍了在允许 (Root) -> Value 函数的情况下使用键路径表达式 \Root.value 的能力。

Swift-evolution 线程：关键路径表达式作为函数

3. Patrick Pijnappel 提出了为 non-open 类实现详尽模式匹配的建议。

由于现在区分了开放类和非开放类，非开放类层次结构应该能够完全匹配。对于添加新子类，不需要添加任何语法就可以完成。

4. Guillaume Lessard 提出了对指针可用性的改进。

该提案为 UnsafePointer、Mutable 和 Raw 引入了一些 quality-of-life 改进。

添加 API 获取一个 UnsafeRawPointer 实例，这是一个从起点推进到给定对齐的实例
在给定 UnsafePointer<T> 的情况下，添加一个 API 获取指向聚合的存储属性的指针 T
将Unsafe[Mutable]Pointer 未选中的下标重命名为包含 unchecked 标签
添加比较任意两种类型的指针的能力

5. Pavel Yaskevich 提出了改进相同类型约束语法的建议。

为了实现改进泛型 UI 的目标，我们提出几项改进措施，为了解决协议和泛型类型之间的语法差距，在关联类型和泛型类型参数相同类型的约束上，隐藏了一些复杂性（视觉上和认知上）。

6. Holly Borla 开始讨论如何简化引入泛型参数的学习曲线。

Swift 的泛型系统具有很强的表达能力，但是要理解具有相关类型的协议、带有 where 子句的泛型签名以及其他泛型特性的完整通用性，是将泛型引入 Swift 项目的一个重大障碍。泛型系统的主要目标是通过改进在 Swift 中编写泛型代码的人体工程学，将具体API抽象为泛型API的学习曲线。本次讨论目的是就实现这一目标的可能方向征求意见，并收集在社区中提出的其他想法。欢迎在文末留言提出问题、评论和想法！

本帖中的许多想法都是由 @Joe_Groff 在改进泛型 UI 中提出的。

7. Nate Cook 提出了一个用于字符串处理的字符类的想法。

声明性字符串处理概述讲述了正则表达式支持的匹配，但没有关于语法和语义的详细信息，将澄清留给后续介绍。

正则表达式的文本提供了关于正则表达式语法的更多细节，例如分隔符和 PCRE-syntax 内部结构，省略了对正则表达式语义的讨论。本帖的目的旨在解决正则表达式语义的目标子集：字符类的定义。我们建议直接在现有的 Character 和 Unicode.Scalar 上和新提出的 API 背景下来处理。

正则表达式中的字符类包括元字符，例如匹配数字的 \d、匹配空格的 \s 和匹配任何字符的 .。单个文字字符也可以被认为是字符类，因为它们至少与自己匹配，并且在不区分大小写的匹配中，与大小写切换的对应字符匹配。因此，将字符类视为正则表达式字面量的任何部分，该部分可以匹配字符串的实际组件。