Swift 周报 第四十三期

前言

本期是 Swift 编辑组整理周报的第四十三期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。

Swift 周报在 GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。

命是弱者的借口，运是强者的谦辞，辉煌与否？且看Swift社区强中意！👊👊👊

周报精选

新闻和社区：iPhone 破发促销、印度市场寻增量，苹果再攀 3 万亿美元高点

提案：函数体 Macros 提案正在审查中

Swift 论坛：Swift 中引入函数体宏

推荐博文：在 SwiftUI 中实战使用 MapKit API

话题讨论：

你是更能接受同性上司还是更能接受异性上司？

上期话题结果

投票结果反映，大多数开发者还是比较担心自己的头发，另外就是身体变胖。久坐缺乏运动会导致一系列的身体健康问题。建议大家抽时间多运动，避免久坐。

新闻和社区

关于 App Store 提交的隐私更新

2023 年 12 月 7 日，第三方 SDK 隐私清单和签名。 第三方软件开发工具包 (SDK) 能够为 App 提供强大的功能，同时也可能会影响用户隐私，而这些影响可能对开发者和用户来说并不明显。请注意，当你将第三方 SDK 与你的 App 搭配使用时，你需要对 App 中使用的相应 SDK 包含的所有代码负责，并且需要了解 SDK 的数据收集和使用实践。

在 WWDC23 (简体中文字幕) 上，我们宣布了新的 SDK 隐私清单和签名，以帮助 App 开发者更好地了解第三方 SDK 如何使用数据、保护软件依赖项并为用户提供额外的隐私保护。从 2024 年春季开始，如果你提交的新 App 或 App 更新添加了 App Store 上的 App 中常用的第三方 SDK，那么你需要包含相应 SDK 的隐私清单。将 SDK 用作二进制文件依赖项时，也需要包含签名。此功能对于所有 App 来说都是向前迈出的重要一步，我们鼓励所有 SDK 采用这项功能，以更好地支持依赖于相应 SDK 的 App。

需要声明原因的 API 的新用例。 如果你上传到 App Store Connect 的新 App 或 App 更新使用了需要声明原因的 API (包括第三方 SDK 使用的 API)，而你没有在 App 的隐私清单中提供批准的原因，那么你会收到通知。根据我们收到的开发者反馈，批准的原因列表已扩展到包含更多用例。如果你的用例可让用户直接受益，但未在现有批准原因列表中，请提交请求 (英文) 以便我们添加新的原因。

从 2024 年春季开始，若要将新 App 或 App 更新上传到 App Store Connect，你需要在 App 的隐私清单中注明批准的原因，以准确反映你的 App 如何使用相应 API。

iPhone 破发促销、印度市场寻增量，苹果再攀 3 万亿美元高点

作为全球科技公司的标杆，苹果公司的市值在今年 8 月初创下了新高，突破了 3 万亿美元的大关。不过，由于手机、PC 等市场的波动，加上外部多种因素的影响，近几月的时间，苹果公司的股价起起伏伏，市场也都在等待苹果何时能够再次站上 3 万亿美元的高点。

四个月的等待后，这一节点被定格在了美国当地时间 12 月 5 日。截至美股当日收盘，苹果公司股价报收于 193.42 美元，上涨 2.11% ，总市值达 3.01 万亿美元。

临近 2023 年年底，苹果公司股价 3 万亿美元的再次冲关，也算是给过去起伏的一年收了个尾。回望过去的一年，作为贡献出近一半收入的产品，iPhone 也未能幸免于整个大环境的下滑。为了提振销量，渠道商不得不降价促销，而新品开售破发加速、华为 5G 的回归更是给了苹果重重一击。

不过，依然需要指出的是，在绝大部分手机品牌亏本做买卖的同时，苹果公司则是赚走了全球超 8 成的利润。另外，印度市场的崛起，也让苹果公司找到了新增量。

Counterpoint 高级分析师 Ivan Lam 对钛媒体 App 表示，“印度俨然已经成为了人口第一大国，而且出生率还不错，年轻群体庞大且消费活跃。对于苹果来说，是未来十年的一个重要潜力市场。”

假日将至，请为你的 App 做好准备

App Store 最繁忙的季节即将到来！确保及时更新你的 App 和游戏，并在岁末假日到来之前做好准备。整个假日季期间同样会开放 App 提交，我们非常期待看到你提交的 App。平均而言，90% 的提交内容会在 24 小时内得到审核。但请注意，在 12 月 22 日至 27 日，完成审核所需的时间可能略长一些。

提案

通过的提案

SE-0411 隔离的默认值表达式 提案通过审查。该提案已在 四十期周报 正在审查的提案模块做了详细介绍。

正在审查的提案

SE-0414 基于区域的隔离 提案正在审查。

Swift Concurrency 将值分配给由 actor 和任务边界确定的隔离域。在不同隔离域中运行的代码可以并发执行，并且通过 Sendable 检查，防止非 Sendable 值跨越隔离边界传递，从而彻底消除对共享可变状态的并发访问。在实践中，这是一个重要的语义限制，因为它禁止了无数据竞争的自然编程模式。

在本文档中，我们提出通过引入一种新的控制流敏感的诊断来放宽这些规则，该诊断确定非 Sendable 值是否可以安全地在隔离边界上传递。通过引入隔离区域的概念，编译器可以保守地推断两个值是否可能相互影响。通过使用隔离区域，语言可以证明在将非 Sendable 值传递过隔离边界后，该值（以及可能引用它的任何其他值）在调用者中不会被使用，从而防止竞争的发生。

SE-0415 函数体 Macros 提案正在审查。

宏通过附加代码来增强 Swift 程序，其中包括新的声明、表达式和语句。目前，宏系统不支持可能希望增强代码的关键方式之一，即合成或更新函数的主体。可以创建具有自己函数主体的新函数，但不能为用户声明的函数提供、增强或替换函数主体。

该提案引入了函数体宏，确切地说：允许根据声明全面合成函数主体，以及通过更多功能增强现有函数主体。这为宏提供了许多新的用例，包括：

• 根据函数声明和一些元数据（例如自动合成传递提供的参数的远程过程调用）全面合成函数主体。
• 通过执行日志/跟踪、检查前置条件或建立不变量来增强函数主体。
• 根据提供的实现替换函数主体。例如，将主体移入在其他地方执行的闭包中，或将主体视为宏“降低”为可执行代码的特定领域语言。

Swift论坛

1. 提议SE-0415：函数体宏

内容概括

SE-0415 提议在 Swift 中引入函数体宏。 该提案的审核期截至 2023 年 12 月 20 日。该提案建议启用一项可通过带有 -enable-experimental-feature BodyMacros 标志的主干开发快照访问的功能。

审核过程鼓励反馈以改进提案。 它要求审阅者评估所解决问题的重要性、提案是否符合 Swift 的方向，并将其与其他语言或库中的类似功能（如果适用）进行比较。 Tony Allevato 作为审核经理负责监督此审核流程。

讨论的序言中提出的一个具体问题提到，所提议的宏可能无法有效地处理从函数体抛出的错误。 有人建议使用一种新的延迟块来捕获抛出的错误，从而允许访问块内的这些错误以进行处理。

所提出的语法示例演示了一个概念，其中 defer 块可能会捕获从函数体抛出的错误并执行报告错误和重新抛出错误等操作。

2. 讨论枚举案例类型签名/插值

内容概括

讨论围绕获取具有关联值的枚举情况的字符串表示，特别是寻求一种为每种情况生成类型化签名或插值的方法。 一个示例枚举了具有关联值及其预期输出签名的各种情况。

当前的方法涉及使用反射，但由于反射元数据对应用程序二进制大小的影响，因此存在可能删除反射元数据的担忧。 另一种考虑的方法是使用宏，但这些可能不适用于较旧的操作系统版本，从而带来兼容性挑战。

该对话强调了与处理重复的枚举案例名称相关的编译器错误，该错误使枚举实例的唯一性变得复杂。

核心需求是为某些枚举案例的所有实例导出一个稳定的 hashValue，无论它们的关联值如何，旨在将具有相同案例名称但不同关联值的实例视为相同的存储目的。 然而，传统的 Hashable 实现不足以实现此目的。

一个探索的想法涉及利用 String(describing:) 生成枚举案例的字符串表示形式，但如果客户端为枚举实现 CustomStringConvertible，则这种方法可能会失败。 人们有兴趣了解如何调用枚举描述的默认 Swift 标准库实现，以解决 CustomStringConvertible 的客户端实现所产生的问题。

3. 讨论~Copyable 类型中不可用的 deinit

内容概括

讨论围绕着 ~Copyable 类型中不存在不可用的 deinit 以及它对程序员构建代码以与本地数据流分析保持一致的依赖展开。

不可破坏类型的概念旨在增强本地数据流分析并提供编译时保证。 它类似于函数的想法，从技术上讲，函数承诺返回一些东西，但实际上却没有，而编译器静态地证明了理论上的不可能。

该提案引入了不可破坏类型（_{Destructible）作为取代}Copyable 的新根类型。 它设想了类型不需要显式反初始化的场景，依赖编译器的静态分析来强制执行预期的清理例程。

讨论对比了使用和不使用此功能时 API 使用的难度，强调了需要显式清理时面临的潜在挑战。 对 API 文档、运行时检查和潜在风险的仔细研究与用于防止错误使用的编译时诊断进行了比较。

对话承认实现此功能的潜在复杂性以及收益是否值得付出努力的不确定性。 它引用了 Scott Meyers 关于使接口易于正确使用且难以错误使用的名言，强调了编程接口简单性和清晰性的重要性。

4. 展示Advent of Code 2023

内容概括

Swift 社区受邀参加“Advent of Code”，这是一项从 12 月 1 日到 12 月 25 日举办的年度编码挑战赛。 这项挑战由 Eric Wastl 组织，涉及日常编码练习，开始时很简单，逐渐变得更具挑战性。

参与者可以使用任何编程语言，但有一个 Swift 团队模板可供那些喜欢 Swift 的人使用。 该模板提供了解决挑战的起点。

加入：

1. 克隆 Swift 团队的入门模板（可选）。
2. 在 Advent of Code 网站上创建一个帐户（参与排行榜所需）。
3. 使用ID 3315857-f51d8ce5加入Swift社区排行榜。

我们鼓励参与者每天使用 Swift 尝试挑战。 排行榜跟踪完成时间，但分数只是为了好玩，可以忽略。

排行榜允许那些想要分享解决方案的人链接到 GitHub 帐户，为参与者提供了互相学习方法的机会。

这是一个社区活动，并不正式隶属于 Swift 项目，旨在整个 12 月享受乐趣、提高 Swift 技能并享受一些编码挑战。 参与者被警告，随着挑战变得更加严峻，挫败感可能会出现！

5. 讨论Swift OpenAPI Generator 1.0.0-alpha.1（候选发布版）已发布（Multipart、base64、过滤、递归类型等）

内容概括

Swift OpenAPI Generator 团队已发布版本 1.0.0-alpha.1，该版本作为即将发布的 1.0 版本的候选版本，预计将在大约两周内发布。 1.0 的主要重点是增强文档和示例，没有计划更改代码。

自 2023 年 5 月以 0.1.0 版本首次开源以来，Swift OpenAPI Generator 已经取得了实质性进展。 合并了 200 多个拉取请求，产生了 24 项更新并引入了重要的新功能。

主要亮点：

• 新功能包括对 Base64 编码数据的支持、文档过滤、递归类型支持、服务器 URL 模板变量支持以及具有类型安全和流式传输的多部分内容类型支持。
• 此外，生成代码的可自定义访问修饰符允许在公共、包（默认）和内部可见性之间进行选择。
• 该版本还包含各种改进和错误修复，例如将 Swift 5.9 更新为最低支持版本、错误处理增强以及生成的代码注释的细化。

重大变更和迁移：

• 该版本包括 API 反馈所必需的重大更改。 提供了将代码从版本 0.3.x 迁移到 1.0.0-alpha.1 的指南，详细说明了潜在的构建错误及其解决方案。

下一步是什么：

• 版本 1.0.0-alpha.1 作为候选版本，邀请反馈意见被考虑用于计划在两周内发布的最终 1.0.0 版本。 鼓励用户测试 alpha 版本以确保与其项目的兼容性。

该团队对贡献者表示感谢，并邀请通过 Swift OpenAPI Generator GitHub 存储库进一步参与。

6. 讨论可编码不正确的 Json 字符串，包含 URL 和十进制存在值

内容概括

该对话探讨了 Swift Codable 协议在处理存在类型时的细微差别，特别是涉及 URL、Decimal 和 AnyEncodable 的可编码行为。

讨论解决了使用存在类型时期望与实际行为之间的差异。 值得注意的是，当抽象具有预期行为（例如，meow()）的 Cat 等类型的实例时，预期 Cat 的所有实例都将统一表现出该行为。 当使用encode()时，内部表示（例如Decimal类型）会出现在最终的JSON字符串中，这会让人感到惊讶，从而导致方法分派和类型编码的混乱。

该演讲深入探讨了 Codable 的基础知识以及存储类型信息以进行解码的必要性。 出于安全性和互操作性原因，可编码省略了编码数据中的类型信息，因此需要在代码中预定义以进行解码。 这种方法允许解码不明确的值，但对类型擦除的值（如 AnyEncodable）带来了挑战，使得在解码期间难以对类型进行逆向工程。 如果解码时不知道类型，则不可能重建原始数据。

所讨论的警告方面围绕着未来可能需要解码的场景。 如果在不考虑未来解码要求的情况下做出编码决策，则可能会使数据检索变得复杂。

最后，讨论暗示了从枚举案例数组中收集枚举时的挑战和注意事项，强调了编码和解码策略的复杂性以及在设计导出或序列化工具时深思熟虑的重要性。

7. 讨论是否可以自动验证值更改并抛出错误？

内容概括

本讨论围绕自动验证值更改的概念展开，旨在消除 CRUD 方法中出现的显式验证调用。 对话的重点是在 Swift 构造中实现自动验证的挑战。

该示例使用 Name 结构来探索拦截值访问以进行实时验证的潜在方法。 然而，诸如计算属性或属性观察器之类的现有机制缺乏对在验证过程中抛出错误的直接支持。 这一限制对在 Swift 结构中无缝实现自动验证造成了重大障碍。

这次对话强调了手动验证的必要性，即使是基本类型，因为从这些基本类型构建的复杂类型会产生复杂性。 例如，讨论介绍了 Employee 结构体，并说明了对其 addr1 和 addr2 属性的手动验证规则的需求，强调尽管基本类型具有验证机制，但手动验证在复杂类型级别至关重要。

尽管函数体宏被认为是另一种潜在的方法，但讨论主要集中在计算变量或动态查找功能是否可以支持自动验证，最终表达了对在 Swift 现有机制中实现它的可行性的怀疑。

提出了两种建议的“手动”方法：

1. 使用 let 代替 var 字段，并在构造函数中加入验证逻辑，使其失败。
2. 在外部执行验证，如果验证失败，则利用 didSet 恢复到之前的值。

这些手动方法旨在在更改期间同步强制验证，确保值保持一致。 但是，后一种方法可能会暂时使不变量无效，但可能适用于可接受同步验证的场景，例如避免由于暂时不正确的值导致的 UI 闪烁。

推荐博文

从预编译的角度理解 Swift 与 Objective-C 及混编机制

摘要： 这篇博客讨论了 Objective-C 的预编译工作机制和与 Xcode 相关的技术细节。Clang Module 提升了编译的健壮性和扩展性，而使用 hmap 技术可以提高编译效率。

Xcode Phases 构建系统中的不同类型代表不同的文件。使用 cocoapods-hmap-built 插件可以节省大型项目的编译时间。Clang Module 和 Swift Module 有相似的概念，而 Swift 与 Objective-C 混编有几种方法可选。利用 VFS 机制可以提升编译效率。

在 SwiftUI 中实战使用 MapKit API

摘要： 这篇 Swift 博客介绍了在 SwiftUI 中使用 MapKit 的基础知识。最新版本的 SwiftUI 引入了新的 MapKit 集成 API ，提供了更全面的功能。

文章示例了如何使用 Marker 和 Annotation 类型在地图上放置标记和自定义视图。还介绍了控制地图初始位置和交互类型的方法。

该博客将在接下来的几周继续深入讨论相机操作、地图样式和用户位置跟踪等主题。

计算机编程语言原理与源码实例讲解：Swift 函数和闭包

摘要： 这篇 Swift 博客介绍了计算机编程语言原理与源码实例中的 Swift 函数和闭包。文章首先介绍了 Swift 作为一种强类型、编译型、面向对象的编程语言的背景。

然后，详细讲解了函数和闭包的核心概念和联系，包括函数的定义、调用和返回值，以及闭包的定义、调用和返回值。

接下来，文章深入探讨了函数和闭包的算法原理，包括函数的接收输入参数、执行操作和返回输出结果的过程，以及闭包的类似过程。

最后，文章通过具体的代码实例展示了函数和闭包的使用方法，并讨论了它们未来的发展趋势和可能面临的挑战。附录部分回答了一些常见问题，帮助读者更好地理解 Swift 函数和闭包的概念和用法。

话题讨论

你是更能接受同性上司还是更能接受异性上司？

1. 性别无关：不在意上司的性别，更关注他们的能力和领导风格。
2. 同性上司：同性上司更容易理解自己的处境和需求。
3. 异性上司：异性上司会带来不同的观点和经验。
4. 不确定：没有明确的偏好，根据情况判断是否接受同性或异性上司。

欢迎在文末留言参与讨论。

关于我们

Swift社区是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容，也整理收集优秀的学习资料。

特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。