前言
本期是 Swift 编辑组自主整理周报的第六十六期，每个模块已初步成型。
Swift 周报在 GitHub 开源[1]，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
若你决定灿烂，山无遮，海无拦。Swift社区与你一起，用黑白两色的眼睛，去观察五彩斑斓的世界！👊👊👊
周报精选
新闻和社区：苹果 1 亿美元投资还不能解除 iPhone16 封杀令？
提案：SE-0453: 向量，固定大小的数组提案正在审查。
Swift 论坛：提议修改和读取访问器
推荐博文：Swift 中间语言（SIL）的生成和使用
话题讨论：
AI 技术迅速发展壮大你有怎样的看法呢？
上期话题结果
图片
从投票结果可以看出，大家对于消费还是保持理智。资本的套路不灵光了。
新闻和社区
苹果 1 亿美元投资还不能解除 iPhone16 封杀令？
2024 年 11 月 22 日
美股科技巨头苹果的最新款智能手机 iPhone 16 系列产品发售后不久便在印度尼西亚市场遭遇困境，目前，苹果正寻求解除印尼对 iPhone 16 的销售禁令。
这一禁令源于苹果在印尼子公司的产品未能满足 40% 本地化率的要求、也没有获得在该国销售的许可，禁令的目的在于保护当地产业和就业。
此前，苹果已经两度提出过解决方案，最初是计划在当地投资近 1000 万美元扩大生产线，对此印尼官方并未做出多少回应，数日后苹果再次提议两年内将在印尼投资近 1 亿美元，印尼方面虽有做出回应，但苹果高管在飞到雅加达后，未能成功与该国工业部长会面。
据印尼当地媒体周五（11月22日）报道，该国工业部周四（11月21日）会见了苹果公司的代表，讨论了苹果公司在两年内投资 1 亿美元的提议，据悉，这笔资金将用于投资该国的一个研发中心项目和专业发展学院，并且苹果还计划从 2025 年 7 月开始在当地生产配件产品组件，专门用于苹果的 AirPods Max。
虽然苹果新的报价已经是之前计划的 10 倍，但印尼政府则是期望苹果能够在 1 亿美元投资上再添上一点，以换取 iPhone 16 禁令的解封和更多准入。
工业部发言人 Febri Hendri Antoni Arif 周四在采访中表示，“当然，从政府的角度来看，我们希望这笔投资更大。”
他表示，更大规模的投资将有助于印尼制造业的发展，并补充称，印尼国内工业有能力支持苹果产品的生产，比如充电器和配件。
Canalys 专注于苹果战略研究的分析师 Le Xuan Chiew 表示，虽然印尼对苹果来说是一个小市场，但它也提供了增长机会，因为它拥有全球第四大人口。
他指出，年轻且精通技术、数字素养不断提高的人口与苹果扩大全球销售的战略是一致的，此外该国还提供了制造和组装的潜力，支持苹果实现供应链多元化的努力。
他还补充道，在这个市场取得成功需要长期的策略，苹果的投资表明了遵守当地法规的承诺，并为未来的增长铺平了道路。（来源：财联社）
消息称苹果正评估电视新品类，智能家居是关键
2024 年 11 月 22 日
科技媒体 MacRumors 昨日（11 月 21 日）发布博文，援引彭博社马克・古尔曼（Mark Gurman）的曝料，消息称苹果公司内部正评估设计和制造“苹果品牌电视”的想法，进一步扩展智能家居生态。
消息称苹果公司正积极探索新的收入来源，加速推进智能家居战略。该媒体认为苹果的智能家居产品获得成功，电视产品可能会出现在未来的产品路线图上。
媒体报道，苹果将推出智能电视的消息最早可以追溯到 2006 年，而一位前苹果高管于 2011 年声称苹果与一家电视制造商达成了协议，相关消息此后愈演愈烈。
乔布斯在谈及电视时曾透露：“我终于搞定了，我想创造一款完全易于使用的集成电视，可以和 iCloud 无缝集成，用户不用摆弄复杂的遥控器”。
相关消息已知持续到 2015 年，《华尔街日报》于 2015 年报道，苹果公司在“1 年前”就放弃了苹果品牌电视的计划。
苹果公司在 2019 年 11 月推出了 Apple TV+ 服务，并在过去五年中不断增加新的电视节目和电影。Apple TV+ 现在拥有相当数量的内容，此外还有 Apple Music 等服务，可以构筑完善的电视生态。
在硬件方面，尽管电视市场仍然被三星、LG 和索尼主导，但苹果公司一直研究尖端显示技术，该媒体认为苹果现在推出电视产品，依然可以吸引大量消费者。（来源：IT之家）
Billie Eilish 当选 2024 年 Apple Music 年度艺人
2024 年 11 月 21 日
Apple 今日宣布 Billie Eilish 当选 Apple Music 年度艺人，以赞颂这位唱作歌手于 2024 年全年带来的卓越影响。
在这一年里，Billie 先是凭她为 Greta Gerwig 执导的影片《Barbie》创作并演唱的主题曲《What Was I Made For?》历史性地第二次荣获奥斯卡奖并捧得两座格莱美奖，之后又发布了自己的第三张专辑《HIT ME HARD AND HIT ME SOFT》。这张既真诚又大胆的专辑代表了这位时代杰出艺人的重大飞跃，也是她音乐生涯迄今的最佳作品。这张专辑刚一发行就在全球 138 个国家和地区的 Apple Music 全类型专辑排行榜登上了冠军宝座。
在那之后，Billie 继续发挥她的文化影响力。今年 8 月，她代表家乡洛杉矶在巴黎运动盛会的闭幕式上表演了金曲《BIRDS OF A FEATHER》，当天她的 Shazam 搜索量也创下了个人纪录。Billie 还与 Charli xcx 合作了今夏的热门单曲《Guess》。目前，她的《HIT ME HARD AND SOFT》巡演正在进行中，一票难求，将把这一年的辉煌成就延续到 2025 年。
今年，Billie 又获得了包括年度制作、年度专辑、年度歌曲在内的七项格莱美奖提名。同时，她也成了首位两度获封 Apple Music 年度艺人的获奖者——她在 2019 年曾当选首届 Apple Music 年度艺人。
这一非凡成就不仅代表了 Apple Music 对 Billie 作品的热爱，也反映了她的创作力之旺盛与持久。她 2019 年的首张专辑《WHEN WE ALL FALL ASLEEP, WHERE DO WE GO? 》今年五月被评为 Apple Music 百大最佳专辑第 30 名。这张专辑让世界认识了一位不到 20 岁的天才艺人，而《HIT ME HARD AND SOFT》则证明，她绝非一闪而过的流星。
“从近十年前第一次听到《Ocean Eyes》开始，我们一直是 Billie 的歌迷和支持者。”Apple Music 内容与编辑高级总监 Rachel Newman 表示，“一位年轻艺人能在这么短的时间里打动这么多人的心，这是非常难得的。过去这一年里，她的演化让我们叹为观止，这不仅是因为她的声音和艺术继续触发着广泛共鸣，更因为她如此勇敢坦荡地绽放——按她自己的意愿，以她自己的方式。”
“从第一天开始，Apple Music 就支持着我的音乐和艺术。在音乐生涯的这个阶段获得年度艺人的认可，我感到荣幸之至。”Billie 告诉 Apple Music。现在，你可以通过空间音频重温 Billie 的全部作品，并庆祝她的非凡成就。同时，别忘了关注 Apple Music 揭晓在 2024 年大放异彩的艺人与歌曲，聆听人气歌单，以及获悉更多 2024 年编辑精选专辑。
苹果计划2026年发布全新Siri：集成先进大模型 更像真人
2024 年 11 月 21 日
11 月 22 日消息，据媒体报道，苹果正在研发更智能、对话能力更强的 Siri，旨在赶超 OpenAI 的 ChatGPT 及其他语音服务。
报道称，新版 Siri 采用更先进的大型语言模型（LLM），苹果希望新 Siri 能进行持续对话，更像人类一样回应问题，更迅速处理更复杂的请求。
全新 Siri 被苹果研发人员称为“LLM Siri”，与今年推出的 Apple Intelligence（苹果智能）一样，这些新功能不会立即被纳入明年的硬件设备中，苹果目前计划最早 2026 年发布新版 Siri。
据了解，在 iOS 18.1、iPadOS 18.1 和 macOS Sequoia 15.1 中，备受关注的 Apple Intelligence 功能正式上线。
iPhone、iPad 和 Mac 将拥有“全系统范围内的 AI 写作助手”——包括邮件、备忘录、信息、Pages，以及第三方应用。
按计划，苹果 iOS 18.2 正式版将在 12 月发布，届时，Apple Intelligence 将正式接入 ChatGPT。
苹果用户不用创建账户就可以免费使用 ChatGPT，Siri 将利用 ChatGPT 的专业知识回答用户问题。（来源：快科技）
提案
正在审查的提案
SE-0452[2] 整数通用参数 提案正在审查。
在本提案中，我们介绍了在字面整数参数上对泛型类型进行参数化的能力。
SE-0453[3] 向量，固定大小的数组 提案正在审查。
本提案为标准库Vector引入了一种新类型，这是一个固定大小的数组。这类似于经典的 C 数组 T[N]、C++ 的 std::array<T, N> 和 Rust 的数组 [T; N]。
Swift论坛
- 评论SF-0011：并发安全通知[4]
Swift Foundation 提案 SF-0011: 并发安全通知 的评审已开启，将持续至 2024 年 11 月 19 日。该提案旨在通过新的 API 提升通知在并发场景中的处理能力，并引入以下三个协议：
- Message：基础协议，用于定义通用消息结构。
- MainActorMessage：继承自 Message，用于需要在主线程上接收的消息。
- AsyncMessage：继承自 Message 和 Sendable，用于支持异步接收的消息。
同时，提案设计了两种 addObserver 方法，分别处理 MainActorMessage 和 AsyncMessage。
关键反馈：
- 关于 MainActorMessage 的约束：
提案需要进一步澄清 MainActorMessage 的 post() 方法是否应被限制为仅在 @MainActor 环境中调用，以确保观察闭包能够同步触发。
应明确 MainActorMessage 是否允许在非 @MainActor 环境中构建，但要求在主线程上观察。
- 关于 AsyncMessage 协议的必要性：
有建议认为 AsyncMessage 协议的 Sendable 要求可能是多余的，可以直接使用 Message 协议，并通过对方法的参数施加约束来满足需求。
如果未来语言支持动态隔离（如 @isolated(parameter)），可能可以通过 Message 协议中的属性进一步简化设计。
- 异步消息处理的优化建议：
当前的 addObserver 方法使用异步观察者闭包，但该闭包可能通过非结构化任务执行，容易引发性能问题，例如过多任务创建销毁会导致开销增加，甚至可能导致拒绝服务攻击。
建议通过结构化并发重新设计 API，例如引入 AsyncSequence 来处理消息观察，从而移除对非结构化任务的依赖并避免引入额外的 ObservationToken。
- 关于 ObservationToken：
当前 ObservationToken 用于支持快速注销观察者，但需要明确在未调用 removeObserver 的情况下，观察者何时被自动取消注册。
提议将 ObservationToken 设计为 ~Copyable 类型，以确保其仅能使用一次并防止被意外丢弃。
总结：该提案为并发通知管理带来了重要改进，但仍有设计细节需要完善，例如协议的约束合理性、API 的性能及安全性优化，以及观察者生命周期管理的明确性。
- 讨论随机“Clock”持续时间[5]
用户尝试实现一个函数，基于通用 Clock 生成一个从零到指定上限的随机持续时间 (Duration)。由于 Clock.Duration 仅受限于 DurationProtocol，直接实现这一功能存在挑战。幸运的是，Swift.Duration 提供了 seconds 和 attoseconds 两个 Int64 组件，可以通过组合它们生成一个随机的 Int128 值（Swift 6 中新增支持），实现随机持续时间计算。
extension Clock where Duration == Swift.Duration {
func randomDuration(upTo maxDuration: Duration) -> Duration {
let random = Int128.random(in: 0..<(Int128(maxDuration.components.seconds) * 1_000_000_000_000_000_000 + Int128(maxDuration.components.attoseconds)))
return Duration(secondsComponent: Int64(random / 1_000_000_000_000_000_000), attosecondsComponent: Int64(random % 1_000_000_000_000_000_000))
}
}关键问题与讨论：
- 通用性限制：
此实现仅适用于 Duration 为 Swift.Duration 的时钟，不适用于其他 DurationProtocol 实现。用户希望找到更通用的方法。
- 非均匀性与运行时性能：
有人指出该方法可能具有非均匀的运行时，且在理论上可能出现运行时间非常长的情况。
然而，在实际应用中，这种情况极少发生。例如，使用简单的拒绝采样算法时，97.5% 的情况下只需一次采样，99.95% 的情况下两次采样即可完成。因此，这种“不均匀性”在实际意义上几乎可以忽略不计。
- 效率与可行性：
尽管方法在某些情况下理论上不够优雅，但其实际运行效率足够高，对绝大多数应用场景而言是合理的解决方案。
总结：该方法利用 Swift.Duration 的组件生成随机持续时间，但受限于特定类型的 Clock，不够通用。此外，尽管存在理论上的非均匀性问题，但在实践中这种方法的效率和可靠性可以满足需求。进一步优化可能需要考虑更通用的 DurationProtocol 支持，以及潜在的性能改进方向。
- 讨论withCheckedContinuation(isolation:function:_:) 中的 SIGSEGV[6]
团队在将代码库迁移到 Swift 6 语言模式 时，发现使用 withCheckedContinuation(isolation:function:_:) 的网络接口与基于 Combine 的任务发布器同时支持的实现，在迁移到 Xcode 16 后，出现了一些 tvOS 18.0 上的崩溃问题。以下是问题描述与社区反馈总结：
问题概述：
- 崩溃日志指向 withCheckedContinuation(isolation:function:_:) 函数，相关调用栈位于 swift::runJobInEstablishedExecutorContext。
- 该问题出现在 Xcode 16 及其后续版本（如 16.1），影响从 iOS 18 开发者测试版 1 至 4 的客户端。
- 崩溃的根本原因与并发全局函数（如 withThrowingTaskGroup、withCheckedThrowingContinuation）在引入 isolation 参数后的行为变化相关。
社区反馈与应对建议：
- 升级与回滚策略：
建议升级至 Xcode 16.1：尽管某些问题依旧未解决，但部分用户报告升级后稳定性有所改善。
回滚到 Xcode 15.4：因 Xcode 16 在特定环境中的兼容性问题，一些团队选择回滚以降低崩溃率，尽管开发人员在升级后可能难以回退。
- 直接修复方法：
将 stdlib 中的崩溃函数直接复制到本地并进行调整（通过复写方式规避问题）。此方法在部分生产环境中已稳定运行数周。
对外部依赖的适配方法：
如果依赖库是预构建的，可以尝试修改符号引用以指向本地修复版本。
注意避免全局替换定义（如使用 @_dynamicReplacement 或类似 fishhook 的动态链接库替换工具）。
- 对每个函数问题的单独解决：
相关函数：包括 withThrowingTaskGroup、withCheckedThrowingContinuation、withCheckedContinuation 等。
独立处理的必要性：这些函数引发崩溃的原因相似，但解决方法可能需要针对每个函数的具体实现进行单独的调整。
- 函数定义与参数顺序的影响：
某些函数（如 TaskLocal.withValue）虽然也添加了 isolation 参数，但因参数顺序不同而避免了崩溃。例如：
当 isolation 被解释为其他类型（如 String）且未被函数主体读取时，崩溃未发生。
而 withCheckedContinuation 将 isolation 放置在闭包之前，导致其尝试将传入的隔离上下文作为闭包使用，从而引发崩溃。
总结：该问题源于并发函数在 Swift 6 中的实现变化，对特定上下文的兼容性不足。尽管有升级工具链的建议，但实际生产中需依赖本地修复和对依赖库的定制适配。此外，函数参数顺序设计和隔离上下文的解析方式也是影响崩溃的潜在原因。开发者需在迁移到 Swift 6 或 Xcode 16 时进行充分测试并实施必要的兼容性修复。
- 提议SE-0453：向量，固定大小的数组[7]
Swift 论坛对提案 SE-0453: Vector（固定大小数组） 的首次评审已开启，将持续至 2024 年 11 月 27 日。本次评审专注于类型的 API 表面和基本行为，暂不讨论名称 Vector 的相关反馈。后续评审会专门讨论命名问题。
提案概述：
提案引入了固定大小的 Vector 类型，其特点是：
- 固定大小：一旦创建，大小不可更改。
- 完全初始化：所有元素必须在初始化时完成初始化，不能动态添加或移除元素。
- 非可复制性（潜在特性）：虽然 Vector 可能不可复制，但其主要独特性在于其固定大小和初始化需求。
核心反馈与讨论：
- 初始化的特殊性：
与其他数据结构不同，Vector 无法通过常规方法（如 init()、reserveCapacity()、append()）操作，因此初始化器需要支持直接生成元素集合。
提案中的初始化器适合 Vector 的独特性，但可能仍不足以覆盖更复杂的初始化模式。
- 关于通用初始化器的建议：
当前的初始化器虽然足够实用，但建议引入更底层的初始化方法，类似于 Array 的 init(unsafeUninitializedCapacity:initializingWith:)，允许开发者通过 UnsafeMutableBufferPointer 手动初始化。
一个更安全的方案是引入一个闭包初始化器，按元素顺序初始化，同时提供对已初始化元素的访问（例如通过未来可能支持的 Span 或 MutableSpan 类型）。这种方法可以让初始化过程利用已有元素，实现排序、打乱等操作。
- 适配性与灵活性：
提案的初始化器被认为过于具体，可能限制开发者实现更复杂的功能场景。设计更通用的基础功能有助于提升 Vector 的适配性。
总结：
提案为 Swift 引入了一个高效的固定大小数组类型，适用于需要确定大小且不可变的数据场景。然而，初始化器的设计需要进一步讨论，以支持更多复杂的模式和用例。评审社区还需探讨是否应该提供更通用的底层功能来满足多样化需求。
- 提议修改和读取访问器[8]
论坛中，针对提案 修改和读取访问器 的讨论主要集中在访问器的命名、语义区分以及潜在的未来扩展。以下是提案要点与社区反馈的总结：
提案要点
- 目标版本与时间表：
该提案未计划纳入 Swift 6.1，即使在接近的分支切割时间（2024 年 11 月 13 日）后，也不会立即生效。
- 是否支持 async 访问器：
当前提案未引入异步访问器（如异步 read 和/或 modify）。
提到这是未来可能探索的方向，同时需要考虑与现有功能的痛点进行整合。
- 命名建议：borrow 和 mutate 替代 read 和 modify：
提案计划将 borrow（借用）和 mutate（变更） 用于更加基础的访问器，这些访问器提供对 self 组件的直接借用或可变借用。
而 read 和 modify 更适合描述基于协程（coroutine）的访问器行为，它们强调操作的临时性和持续时长。
- 语义区分：
get 和 set：
表示访问器的瞬时性和最终性，传递数据的所有权，而无需持续的操作。
read 和 modify：
强调活动的持续时间，为某一实体提供临时直接访问权限，而非所有权转移。
举例：读取朋友的表情或让锁匠修改前门，均是具有开始和结束时间的活动，不涉及对象所有权转移。
- 未来方向：投影访问器（Projection Accessors）：
投影访问器可返回与基础对象等长的借用值，使用borrow 和 mutate更符合其语义。
此类访问器能拓展当前存储属性的语义，并为 Swift 提供更灵活的借用模型。
反馈与讨论
- 关于词汇选择的细致区分：
社区成员建议 borrow 和 mutate 是否能替代 read 和 modify，但提案认为它们有显著的语义差异：
read 和 modify 强调基于协程的临时性与操作持续时长；
borrow 和 mutate 则适合表示直接的内存借用。
- 词义对比与命名合理性：
提案反驳了将 read 视为 get 同义词的观点，强调了两者的语义细微差异。
参考词典，read 和 borrow 或 modify 和 mutate 并非严格同义，且其语境含义差异足以避免长期混淆。
- 生命周期与类型安全性：
基于协程的 read 和 modify 访问器，其操作对象仅在访问期间物化，不适合用于建模包含关系（containment）。
在处理非可逃类型（non-escapable types）时，这种差异会影响生命周期语义，成为至关重要的问题。
总结:
提案中的命名设计从语义、生命周期管理与未来扩展性等角度出发，避免了简单的词汇替换以确保语义精确性。当前提案专注于基础访问器功能，但也为未来的功能（如异步访问器与投影访问器）留出了扩展空间。
