Swift 周报 第五期

前言

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 改进。

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

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​​​ 和 匹配任何字符的 ​​.​​。单个文字字符也可以被认为是字符类，因为它们至少与自己匹配，并且在不区分大小写的匹配中，与大小写切换的对应字符匹配。因此，将字符类视为正则表达式字面量的任何部分，该部分可以匹配字符串的实际组件。

关于我们

我们是由 Swift 爱好者共同维护，我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术内容，也整理收集优秀的学习资料。

感谢 SwiftWeekly 与我们的合作，开启 Swift 周报中文版发布之旅。