Swift 周报第十期

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

前言

前几期周报内容是同步翻译的英文版周报，目前英文版停更，周报停滞半年多。经过多次讨论，我们决定重启周报，分模块整理内容同步给大家。

周报内容模块分为：新闻、提案、Swift论坛、推荐博文。初期计划每两周发布一期，欢迎志同道合的朋友一起加入周报整理。

昨日的生活与工作是否也曾迷茫？对新技术渴望突破的心是否依旧执着？Swift社区，为你的技术栈添砖加瓦，你，准备好了吗？

新闻和社区

苹果先买后付服务被警告：破坏这一新兴行业的竞争

据英国《金融时报》7月27日报道，美国消费者金融保护局罗希特·乔普拉向硅谷发出警告。大型科技公司进入“先买后付”贷款业务会破坏这一新兴行业的竞争，他还对客户数据的使用提出了质疑。此前6月6日苹果公司在年度开发者大会上推出“先买后付”的“Apple Pay Later”服务，允许用户6周内分4期付款，期间不产生利息等其他费用。（via 泰山财经）

与 App Store 专家会面交流

准备好与专家在线交流探讨，了解如何充分利用 App Store 的功能。探索如何吸引新顾客、测试营销策略、添加订阅等等。在整个 8 月，苹果官方将在多个时区以多种语言进行实时演讲和答疑。如果您也是苹果开发者的话，最近肯定收到了相关的邮件邀请吧，不知道您是否参加了本次会面交流呢？（Apple Developer Program）

即将从 XML Feed 过渡到 App Store Connect API

App Store Connect REST API 让您可以跨各种开发者工具自定义任务并实现任务自动化，使工作流程更灵活、更高效。从 2022 年 11 月开始，您将需要使用此 API 来代替 XML Feed，从而实现对 App 内购买项目、订阅、元数据和 App 定价的自动化管理。XML Feed 将继续为现有的 Game Center 管理功能提供支持。（Apple Developer News）

新功能 RoomPlan

使用 RoomPlan 创建房间的 3D 户型图，包括家具的尺寸和类型等关键特征。这个是由 ARKit 提供支持的全新 Swift API 能够利用 iPhone 和 iPad 上的摄像头和激光雷达扫描仪将现实环境带入您的 App 中。

使用详情可以观看 WWDC22 中的使用 RoomPlan 创建参数 3D 房间扫描

立即注册 WWDC22 实验室和聊天室

注册实验室和线上聊天室，即可在一整周内与 Apple 工程师、设计师和专家在线交流。

已推出 Xcode 14 Beta 版

包含了适用于所有 Apple 平台 SDK 的 Xcode 14 Beta 版现已推出。利用简洁且强大的 Swift 和 SwiftUI 以及全新的跨平台 App 体验，使用编辑器的增强功能更快捷地编写代码，并着手开始进行从 Xcode Cloud 到 TestFlight 以及 App Store 的测试和部署。

下载 Xcode 14 Beta 版

提案

通过的提案

SE-0352: 隐式开放的存在类型 状态：Swift 5.7 已实现
Swift 中的存在类型允许存储一个特定类型为未知的值，且可能在运行时更改。被存储值的动态类型，我们称为存在类型的底层类型，仅由它遵循的协议集以及潜在的超类知道。尽管存在类型对于表达动态类型的值非常有用，但由于它们的动态性质，它们受到一定限制。最近的提议使存在类型更加明确，以帮助开发人员理解这种动态性质，并通过消除一些限制使存在类型更具表现力。但是存在类型中的基本类型仍然存在，一旦你有一个存在类型的值，你就很难对其使用泛型。开发者通常会遇到 protocol 'P' as a type cannot conform to itself 这样的报错问题。

SE-0352: 隐式开放的存在类型 已于 2022 年 5 月 18 日完成，核心团队已决定接受该提案。第二次审查的重点是关注向前兼容性，当一个调用唤起一个隐式开放的存在类型，必须被抹除类型以防止存在的动态类型内存泄漏到返回值中。当存在类型的表达能力增加，我们可能会有能力使用一个更具体的类型作为这一个调用的返回类型，这可能造成源中断。为了避免这种情况，该提案要求在调用中显式地作为任何 P 类型注释，其中当前可以表达的返回类型将丢弃对被类型擦除的原始关联类型的约束，如提案中的示例所示：

protocol P {
  associatedtype A
}
protocol Q {
  associatedtype B: P where B.A == Int
}

func getP<T: P>(_ p: T)
func getBFromQ<T: Q>(_ q: T) -> T.B { ... }

func eraseQAssoc(q: any Q) {
  let x = getBFromQ(q)          // 错误，必须指定 "as any P" 由于缺少 T.B.A == Int 的约束
  let y = getBFromQ(q) as any P // 可以, 明确抛弃约束
}

SE-0353: 受约束的存在类型 状态：Swift 5.7 已实现
存在类型弥补了 Swift 类型系统中的抽象能力。与泛型一样，它们使函数能够获取和返回多种可能的类型。与泛型参数类型不同，存在类型在作为输入传递给函数时不需要预先知道。此外，当从函数返回时，可以删除具体类型（隐藏在协议接口后面）。在这个领域出现了一系列活动，SE-0309 解除了对使用具有关联类型的协议作为存在类型的剩余限制，而 SE-0346 为关联类型协议的轻量级约束语法铺平了道路。该提案直接基于这些想法，旨在在存在类型的上下文中重用轻量级关联类型约束的语法。

1	any Collection<String>

SE-0356: Swift 代码片段
该提案描述了编写成为片段的新形式示例代码的约定。片段是简短的单文件示例，可以在 Swift 包中构建和运行，可以访问该包中的其他代码，并且可以以多种方式使用。

正在审查的提案

SE-0359: 构建时间常数值 状态：已接受
构建时间常数值是一个 Swift 语言特性，要求在编译时知道某些值。这是通过属性、@const、约束属性和函数参数来实现的，以使其具有编译时可知的值。这些信息为未来更丰富的编译时特性奠定了基础，例如在编译时提取和验证值。

SE-0362: 即将到来的语言改进的逐渐采用 状态：已接受
Swift 6 积累了许多对语言有源码兼容性影响的改进，从而在以前的语言模式（Swift 4.x 和 Swift 5.x）中默认情况下无法启用它们。这些改进已经在背后为 Swift 6 语言模式的 Swift 编译器中实现，但他们对于开发者是无法访问的，并将持续直到 Swift 6 作为一个可获得的语言模式。这有很多原因，为什么我们应该思考尽快提供这些改动。

开发者希望很快从这些改进中受益，而不是等到 Swift 6 可用。
向开发者提供这些改进比 Swift 6 提供更多体验优先级更高，如果有必要，允许我们针对 Swift 6 进一步调试它们。
对于某些模块，所有在 Swift 6 中改动的总数或许会造成迁移繁重，并且在 Swift 4.x/5.x 中逐一采纳这些语言改动，可以使过渡期路径变得丝滑。

一些提案已经引入了定制解决方案来提供迁移路径：SE-0337 添加了 -warn-concurrency 在 Swift 4.x/5.x 中启用与 Sendable 相关检查的警告。 SE-0354 添加标志 -enable-bare-slash-regex 以启用原始 /.../ 正则表达式语法。尽管它不是提案的一部分，但对 SE-0335 的讨论包括对编译器标志的请求，以在存在类型上要求使用 any 。这些都具有相同的风格，即选择现有的 Swift 4.x/5.x 代码进行改进，这些改进将出现在 Swift 6 中。

这个提议明确地包含了零碎的、有意采用的特性，这些特性在 Swift 6 之前出于源代码兼容性的原因而保留。它为逐步采用 Swift 6 特性建立了一条直接路径，以在 Swift 4.x/5.x 代码库中获得它们的优势，并顺利迁移到 Swift 6 语言模式。开发人员可以使用新的编译器标志 -enable-upcoming-feature X 为该模块启用名为 X 的特定功能，并且可以以这种方式指定多个功能。当开发人员移动到下一个主要语言版本时，该语言版本将隐含 X 并且编译器标志将被拒绝。这样，即将推出的功能标志只会累积到下一个主要的 Swift 语言版本，然后被清除，所以我们不会将语言分拆成不兼容的方言。

Swift论坛

SwiftUI 中的新功能围绕 WWDC2022-10052 内容进行讨论
Swift 正则表达式围绕 WWDC2022-110357 内容进行讨论
SwiftUI 导航围绕 WWDC2022-10054 内容进行讨论
Swift 图表围绕 WWDC2022-10137 内容进行讨论
使用 cmake 构建 swift 而不是 build-script。

build-script 是 build-script-impl 的 python 包装器，本身是一个 shell 脚本，然后运行 CMake，执行可以构建项目的工作主体。例如，如果您想执行 utils/build-script -x，将调用 cmake -G Xcode。

Visual Studio Code 增加扩展包支持 Swift 开发
SwiftNIO _ChannelInboundHandler 与 DocC 不兼容

在阅读 swift-biome 中的 SwiftNIO 文档时，遇到一个问题。文档其中引用了 3 个带下划线的属性。例如：_ChannelInboundHandler、_EmittingChannelHandler 等，但是这些属性在 swift-biome 和其他基于 SymbolGraphGen 的工具是不可见的，包括 DocC。