前言

本期是 Swift 編輯組自主整理周報(bào)的第六十六期，每個(gè)模塊已初步成型。

Swift 周報(bào)在 GitHub 開源[1]，歡迎提交 issue，投稿或推薦內(nèi)容。目前計(jì)劃每兩周周一發(fā)布，歡迎志同道合的朋友一起加入周報(bào)整理。

若你決定燦爛，山無遮，海無攔。Swift社區(qū)與你一起，用黑白兩色的眼睛，去觀察五彩斑斕的世界！??????

周報(bào)精選

新聞和社區(qū)：蘋果 1 億美元投資還不能解除 iPhone16 封殺令？

提案：SE-0453: 向量，固定大小的數(shù)組提案正在審查。

Swift 論壇：提議修改和讀取訪問器

推薦博文：Swift 中間語言（SIL）的生成和使用

話題討論：

AI 技術(shù)迅速發(fā)展壯大你有怎樣的看法呢？

上期話題結(jié)果

圖片

從投票結(jié)果可以看出，大家對(duì)于消費(fèi)還是保持理智。資本的套路不靈光了。

新聞和社區(qū)

蘋果 1 億美元投資還不能解除 iPhone16 封殺令？

2024 年 11 月 22 日

美股科技巨頭蘋果的最新款智能手機(jī) iPhone 16 系列產(chǎn)品發(fā)售后不久便在印度尼西亞市場(chǎng)遭遇困境，目前，蘋果正尋求解除印尼對(duì) iPhone 16 的銷售禁令。

這一禁令源于蘋果在印尼子公司的產(chǎn)品未能滿足 40% 本地化率的要求、也沒有獲得在該國銷售的許可，禁令的目的在于保護(hù)當(dāng)?shù)禺a(chǎn)業(yè)和就業(yè)。

此前，蘋果已經(jīng)兩度提出過解決方案，最初是計(jì)劃在當(dāng)?shù)赝顿Y近 1000 萬美元擴(kuò)大生產(chǎn)線，對(duì)此印尼官方并未做出多少回應(yīng)，數(shù)日后蘋果再次提議兩年內(nèi)將在印尼投資近 1 億美元，印尼方面雖有做出回應(yīng)，但蘋果高管在飛到雅加達(dá)后，未能成功與該國工業(yè)部長會(huì)面。

據(jù)印尼當(dāng)?shù)孛襟w周五（11月22日）報(bào)道，該國工業(yè)部周四（11月21日）會(huì)見了蘋果公司的代表，討論了蘋果公司在兩年內(nèi)投資 1 億美元的提議，據(jù)悉，這筆資金將用于投資該國的一個(gè)研發(fā)中心項(xiàng)目和專業(yè)發(fā)展學(xué)院，并且蘋果還計(jì)劃從 2025 年 7 月開始在當(dāng)?shù)厣a(chǎn)配件產(chǎn)品組件，專門用于蘋果的 AirPods Max。

雖然蘋果新的報(bào)價(jià)已經(jīng)是之前計(jì)劃的 10 倍，但印尼政府則是期望蘋果能夠在 1 億美元投資上再添上一點(diǎn)，以換取 iPhone 16 禁令的解封和更多準(zhǔn)入。

工業(yè)部發(fā)言人 Febri Hendri Antoni Arif 周四在采訪中表示，“當(dāng)然，從政府的角度來看，我們希望這筆投資更大?！?/p>

他表示，更大規(guī)模的投資將有助于印尼制造業(yè)的發(fā)展，并補(bǔ)充稱，印尼國內(nèi)工業(yè)有能力支持蘋果產(chǎn)品的生產(chǎn)，比如充電器和配件。

Canalys 專注于蘋果戰(zhàn)略研究的分析師 Le Xuan Chiew 表示，雖然印尼對(duì)蘋果來說是一個(gè)小市場(chǎng)，但它也提供了增長機(jī)會(huì)，因?yàn)樗鼡碛腥虻谒拇笕丝凇?/p>

他指出，年輕且精通技術(shù)、數(shù)字素養(yǎng)不斷提高的人口與蘋果擴(kuò)大全球銷售的戰(zhàn)略是一致的，此外該國還提供了制造和組裝的潛力，支持蘋果實(shí)現(xiàn)供應(yīng)鏈多元化的努力。

他還補(bǔ)充道，在這個(gè)市場(chǎng)取得成功需要長期的策略，蘋果的投資表明了遵守當(dāng)?shù)胤ㄒ?guī)的承諾，并為未來的增長鋪平了道路。（來源：財(cái)聯(lián)社）

消息稱蘋果正評(píng)估電視新品類，智能家居是關(guān)鍵

2024 年 11 月 22 日

科技媒體 MacRumors 昨日（11 月 21 日）發(fā)布博文，援引彭博社馬克?古爾曼（Mark Gurman）的曝料，消息稱蘋果公司內(nèi)部正評(píng)估設(shè)計(jì)和制造“蘋果品牌電視”的想法，進(jìn)一步擴(kuò)展智能家居生態(tài)。

消息稱蘋果公司正積極探索新的收入來源，加速推進(jìn)智能家居戰(zhàn)略。該媒體認(rèn)為蘋果的智能家居產(chǎn)品獲得成功，電視產(chǎn)品可能會(huì)出現(xiàn)在未來的產(chǎn)品路線圖上。

媒體報(bào)道，蘋果將推出智能電視的消息最早可以追溯到 2006 年，而一位前蘋果高管于 2011 年聲稱蘋果與一家電視制造商達(dá)成了協(xié)議，相關(guān)消息此后愈演愈烈。

喬布斯在談及電視時(shí)曾透露：“我終于搞定了，我想創(chuàng)造一款完全易于使用的集成電視，可以和 iCloud 無縫集成，用戶不用擺弄復(fù)雜的遙控器”。

相關(guān)消息已知持續(xù)到 2015 年，《華爾街日?qǐng)?bào)》于 2015 年報(bào)道，蘋果公司在“1 年前”就放棄了蘋果品牌電視的計(jì)劃。

蘋果公司在 2019 年 11 月推出了 Apple TV+ 服務(wù)，并在過去五年中不斷增加新的電視節(jié)目和電影。Apple TV+ 現(xiàn)在擁有相當(dāng)數(shù)量的內(nèi)容，此外還有 Apple Music 等服務(wù)，可以構(gòu)筑完善的電視生態(tài)。

在硬件方面，盡管電視市場(chǎng)仍然被三星、LG 和索尼主導(dǎo)，但蘋果公司一直研究尖端顯示技術(shù)，該媒體認(rèn)為蘋果現(xiàn)在推出電視產(chǎn)品，依然可以吸引大量消費(fèi)者。（來源：IT之家）

Billie Eilish 當(dāng)選 2024 年 Apple Music 年度藝人

2024 年 11 月 21 日

Apple 今日宣布 Billie Eilish 當(dāng)選 Apple Music 年度藝人，以贊頌這位唱作歌手于 2024 年全年帶來的卓越影響。

在這一年里，Billie 先是憑她為 Greta Gerwig 執(zhí)導(dǎo)的影片《Barbie》創(chuàng)作并演唱的主題曲《What Was I Made For?》歷史性地第二次榮獲奧斯卡獎(jiǎng)并捧得兩座格萊美獎(jiǎng)，之后又發(fā)布了自己的第三張專輯《HIT ME HARD AND HIT ME SOFT》。這張既真誠又大膽的專輯代表了這位時(shí)代杰出藝人的重大飛躍，也是她音樂生涯迄今的最佳作品。這張專輯剛一發(fā)行就在全球 138 個(gè)國家和地區(qū)的 Apple Music 全類型專輯排行榜登上了冠軍寶座。

在那之后，Billie 繼續(xù)發(fā)揮她的文化影響力。今年 8 月，她代表家鄉(xiāng)洛杉磯在巴黎運(yùn)動(dòng)盛會(huì)的閉幕式上表演了金曲《BIRDS OF A FEATHER》，當(dāng)天她的 Shazam 搜索量也創(chuàng)下了個(gè)人紀(jì)錄。Billie 還與 Charli xcx 合作了今夏的熱門單曲《Guess》。目前，她的《HIT ME HARD AND SOFT》巡演正在進(jìn)行中，一票難求，將把這一年的輝煌成就延續(xù)到 2025 年。

今年，Billie 又獲得了包括年度制作、年度專輯、年度歌曲在內(nèi)的七項(xiàng)格萊美獎(jiǎng)提名。同時(shí)，她也成了首位兩度獲封 Apple Music 年度藝人的獲獎(jiǎng)?wù)摺?2019 年曾當(dāng)選首屆 Apple Music 年度藝人。

這一非凡成就不僅代表了 Apple Music 對(duì) Billie 作品的熱愛，也反映了她的創(chuàng)作力之旺盛與持久。她 2019 年的首張專輯《WHEN WE ALL FALL ASLEEP, WHERE DO WE GO? 》今年五月被評(píng)為 Apple Music 百大最佳專輯第 30 名。這張專輯讓世界認(rèn)識(shí)了一位不到 20 歲的天才藝人，而《HIT ME HARD AND SOFT》則證明，她絕非一閃而過的流星。

“從近十年前第一次聽到《Ocean Eyes》開始，我們一直是 Billie 的歌迷和支持者?！盇pple Music 內(nèi)容與編輯高級(jí)總監(jiān) Rachel Newman 表示，“一位年輕藝人能在這么短的時(shí)間里打動(dòng)這么多人的心，這是非常難得的。過去這一年里，她的演化讓我們嘆為觀止，這不僅是因?yàn)樗穆曇艉退囆g(shù)繼續(xù)觸發(fā)著廣泛共鳴，更因?yàn)樗绱擞赂姨故幍鼐`放——按她自己的意愿，以她自己的方式。”

“從第一天開始，Apple Music 就支持著我的音樂和藝術(shù)。在音樂生涯的這個(gè)階段獲得年度藝人的認(rèn)可，我感到榮幸之至。”Billie 告訴 Apple Music?，F(xiàn)在，你可以通過空間音頻重溫 Billie 的全部作品，并慶祝她的非凡成就。同時(shí)，別忘了關(guān)注 Apple Music 揭曉在 2024 年大放異彩的藝人與歌曲，聆聽人氣歌單，以及獲悉更多 2024 年編輯精選專輯。

蘋果計(jì)劃2026年發(fā)布全新Siri：集成先進(jìn)大模型 更像真人

2024 年 11 月 21 日

11 月 22 日消息，據(jù)媒體報(bào)道，蘋果正在研發(fā)更智能、對(duì)話能力更強(qiáng)的 Siri，旨在趕超 OpenAI 的 ChatGPT 及其他語音服務(wù)。

報(bào)道稱，新版 Siri 采用更先進(jìn)的大型語言模型（LLM），蘋果希望新 Siri 能進(jìn)行持續(xù)對(duì)話，更像人類一樣回應(yīng)問題，更迅速處理更復(fù)雜的請(qǐng)求。

全新 Siri 被蘋果研發(fā)人員稱為“LLM Siri”，與今年推出的 Apple Intelligence（蘋果智能）一樣，這些新功能不會(huì)立即被納入明年的硬件設(shè)備中，蘋果目前計(jì)劃最早 2026 年發(fā)布新版 Siri。

據(jù)了解，在 iOS 18.1、iPadOS 18.1 和 macOS Sequoia 15.1 中，備受關(guān)注的 Apple Intelligence 功能正式上線。

iPhone、iPad 和 Mac 將擁有“全系統(tǒng)范圍內(nèi)的 AI 寫作助手”——包括郵件、備忘錄、信息、Pages，以及第三方應(yīng)用。

按計(jì)劃，蘋果 iOS 18.2 正式版將在 12 月發(fā)布，屆時(shí)，Apple Intelligence 將正式接入 ChatGPT。

蘋果用戶不用創(chuàng)建賬戶就可以免費(fèi)使用 ChatGPT，Siri 將利用 ChatGPT 的專業(yè)知識(shí)回答用戶問題。（來源：快科技）

提案

正在審查的提案

SE-0452[2] 整數(shù)通用參數(shù) 提案正在審查。

在本提案中，我們介紹了在字面整數(shù)參數(shù)上對(duì)泛型類型進(jìn)行參數(shù)化的能力。

SE-0453[3] 向量，固定大小的數(shù)組 提案正在審查。

本提案為標(biāo)準(zhǔn)庫Vector引入了一種新類型，這是一個(gè)固定大小的數(shù)組。這類似于經(jīng)典的 C 數(shù)組 T[N]、C++ 的 std::array<T, N> 和 Rust 的數(shù)組 [T; N]。

Swift論壇

• 評(píng)論SF-0011：并發(fā)安全通知[4]

Swift Foundation 提案 SF-0011: 并發(fā)安全通知 的評(píng)審已開啟，將持續(xù)至 2024 年 11 月 19 日。該提案旨在通過新的 API 提升通知在并發(fā)場(chǎng)景中的處理能力，并引入以下三個(gè)協(xié)議：

• Message：基礎(chǔ)協(xié)議，用于定義通用消息結(jié)構(gòu)。
• MainActorMessage：繼承自 Message，用于需要在主線程上接收的消息。
• AsyncMessage：繼承自 Message 和 Sendable，用于支持異步接收的消息。

同時(shí)，提案設(shè)計(jì)了兩種 addObserver 方法，分別處理 MainActorMessage 和 AsyncMessage。

關(guān)鍵反饋：

1. 關(guān)于 MainActorMessage 的約束：

提案需要進(jìn)一步澄清 MainActorMessage 的 post() 方法是否應(yīng)被限制為僅在 @MainActor 環(huán)境中調(diào)用，以確保觀察閉包能夠同步觸發(fā)。

應(yīng)明確 MainActorMessage 是否允許在非 @MainActor 環(huán)境中構(gòu)建，但要求在主線程上觀察。

2. 關(guān)于 AsyncMessage 協(xié)議的必要性：

有建議認(rèn)為 AsyncMessage 協(xié)議的 Sendable 要求可能是多余的，可以直接使用 Message 協(xié)議，并通過對(duì)方法的參數(shù)施加約束來滿足需求。

如果未來語言支持動(dòng)態(tài)隔離（如 @isolated(parameter)），可能可以通過 Message 協(xié)議中的屬性進(jìn)一步簡化設(shè)計(jì)。

3. 異步消息處理的優(yōu)化建議：

當(dāng)前的 addObserver 方法使用異步觀察者閉包，但該閉包可能通過非結(jié)構(gòu)化任務(wù)執(zhí)行，容易引發(fā)性能問題，例如過多任務(wù)創(chuàng)建銷毀會(huì)導(dǎo)致開銷增加，甚至可能導(dǎo)致拒絕服務(wù)攻擊。

建議通過結(jié)構(gòu)化并發(fā)重新設(shè)計(jì) API，例如引入 AsyncSequence 來處理消息觀察，從而移除對(duì)非結(jié)構(gòu)化任務(wù)的依賴并避免引入額外的 ObservationToken。

4. 關(guān)于 ObservationToken：

當(dāng)前 ObservationToken 用于支持快速注銷觀察者，但需要明確在未調(diào)用 removeObserver 的情況下，觀察者何時(shí)被自動(dòng)取消注冊(cè)。

提議將 ObservationToken 設(shè)計(jì)為 ~Copyable 類型，以確保其僅能使用一次并防止被意外丟棄。

總結(jié)：該提案為并發(fā)通知管理帶來了重要改進(jìn)，但仍有設(shè)計(jì)細(xì)節(jié)需要完善，例如協(xié)議的約束合理性、API 的性能及安全性優(yōu)化，以及觀察者生命周期管理的明確性。

2. 討論隨機(jī)“Clock”持續(xù)時(shí)間[5]

用戶嘗試實(shí)現(xiàn)一個(gè)函數(shù)，基于通用 Clock 生成一個(gè)從零到指定上限的隨機(jī)持續(xù)時(shí)間 (Duration)。由于 Clock.Duration 僅受限于 DurationProtocol，直接實(shí)現(xiàn)這一功能存在挑戰(zhàn)。幸運(yùn)的是，Swift.Duration 提供了 seconds 和 attoseconds 兩個(gè) Int64 組件，可以通過組合它們生成一個(gè)隨機(jī)的 Int128 值（Swift 6 中新增支持），實(shí)現(xiàn)隨機(jī)持續(xù)時(shí)間計(jì)算。

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))
  }
}

關(guān)鍵問題與討論：

1. 通用性限制：

此實(shí)現(xiàn)僅適用于 Duration 為 Swift.Duration 的時(shí)鐘，不適用于其他 DurationProtocol 實(shí)現(xiàn)。用戶希望找到更通用的方法。

2. 非均勻性與運(yùn)行時(shí)性能：

有人指出該方法可能具有非均勻的運(yùn)行時(shí)，且在理論上可能出現(xiàn)運(yùn)行時(shí)間非常長的情況。

然而，在實(shí)際應(yīng)用中，這種情況極少發(fā)生。例如，使用簡單的拒絕采樣算法時(shí)，97.5% 的情況下只需一次采樣，99.95% 的情況下兩次采樣即可完成。因此，這種“不均勻性”在實(shí)際意義上幾乎可以忽略不計(jì)。

3. 效率與可行性：

盡管方法在某些情況下理論上不夠優(yōu)雅，但其實(shí)際運(yùn)行效率足夠高，對(duì)絕大多數(shù)應(yīng)用場(chǎng)景而言是合理的解決方案。

總結(jié)：該方法利用 Swift.Duration 的組件生成隨機(jī)持續(xù)時(shí)間，但受限于特定類型的 Clock，不夠通用。此外，盡管存在理論上的非均勻性問題，但在實(shí)踐中這種方法的效率和可靠性可以滿足需求。進(jìn)一步優(yōu)化可能需要考慮更通用的 DurationProtocol 支持，以及潛在的性能改進(jìn)方向。

3. 討論withCheckedContinuation(isolation:function:_:) 中的 SIGSEGV[6]

團(tuán)隊(duì)在將代碼庫遷移到 Swift 6 語言模式 時(shí)，發(fā)現(xiàn)使用 withCheckedContinuation(isolation:function:_:) 的網(wǎng)絡(luò)接口與基于 Combine 的任務(wù)發(fā)布器同時(shí)支持的實(shí)現(xiàn)，在遷移到 Xcode 16 后，出現(xiàn)了一些 tvOS 18.0 上的崩潰問題。以下是問題描述與社區(qū)反饋總結(jié)：

問題概述：

• 崩潰日志指向 withCheckedContinuation(isolation:function:_:) 函數(shù)，相關(guān)調(diào)用棧位于 swift::runJobInEstablishedExecutorContext。
• 該問題出現(xiàn)在 Xcode 16 及其后續(xù)版本（如 16.1），影響從 iOS 18 開發(fā)者測(cè)試版 1 至 4 的客戶端。
• 崩潰的根本原因與并發(fā)全局函數(shù)（如 withThrowingTaskGroup、withCheckedThrowingContinuation）在引入 isolation 參數(shù)后的行為變化相關(guān)。

社區(qū)反饋與應(yīng)對(duì)建議：

1. 升級(jí)與回滾策略：

建議升級(jí)至 Xcode 16.1：盡管某些問題依舊未解決，但部分用戶報(bào)告升級(jí)后穩(wěn)定性有所改善。

回滾到 Xcode 15.4：因 Xcode 16 在特定環(huán)境中的兼容性問題，一些團(tuán)隊(duì)選擇回滾以降低崩潰率，盡管開發(fā)人員在升級(jí)后可能難以回退。

2. 直接修復(fù)方法：

將 stdlib 中的崩潰函數(shù)直接復(fù)制到本地并進(jìn)行調(diào)整（通過復(fù)寫方式規(guī)避問題）。此方法在部分生產(chǎn)環(huán)境中已穩(wěn)定運(yùn)行數(shù)周。

對(duì)外部依賴的適配方法：

如果依賴庫是預(yù)構(gòu)建的，可以嘗試修改符號(hào)引用以指向本地修復(fù)版本。

注意避免全局替換定義（如使用 @_dynamicReplacement 或類似 fishhook 的動(dòng)態(tài)鏈接庫替換工具）。

3. 對(duì)每個(gè)函數(shù)問題的單獨(dú)解決：

相關(guān)函數(shù)：包括 withThrowingTaskGroup、withCheckedThrowingContinuation、withCheckedContinuation 等。

獨(dú)立處理的必要性：這些函數(shù)引發(fā)崩潰的原因相似，但解決方法可能需要針對(duì)每個(gè)函數(shù)的具體實(shí)現(xiàn)進(jìn)行單獨(dú)的調(diào)整。

4. 函數(shù)定義與參數(shù)順序的影響：

某些函數(shù)（如 TaskLocal.withValue）雖然也添加了 isolation 參數(shù)，但因參數(shù)順序不同而避免了崩潰。例如：

當(dāng) isolation 被解釋為其他類型（如 String）且未被函數(shù)主體讀取時(shí)，崩潰未發(fā)生。

而 withCheckedContinuation 將 isolation 放置在閉包之前，導(dǎo)致其嘗試將傳入的隔離上下文作為閉包使用，從而引發(fā)崩潰。

總結(jié)：該問題源于并發(fā)函數(shù)在 Swift 6 中的實(shí)現(xiàn)變化，對(duì)特定上下文的兼容性不足。盡管有升級(jí)工具鏈的建議，但實(shí)際生產(chǎn)中需依賴本地修復(fù)和對(duì)依賴庫的定制適配。此外，函數(shù)參數(shù)順序設(shè)計(jì)和隔離上下文的解析方式也是影響崩潰的潛在原因。開發(fā)者需在遷移到 Swift 6 或 Xcode 16 時(shí)進(jìn)行充分測(cè)試并實(shí)施必要的兼容性修復(fù)。

4. 提議SE-0453：向量，固定大小的數(shù)組[7]

Swift 論壇對(duì)提案 SE-0453: Vector（固定大小數(shù)組） 的首次評(píng)審已開啟，將持續(xù)至 2024 年 11 月 27 日。本次評(píng)審專注于類型的 API 表面和基本行為，暫不討論名稱 Vector 的相關(guān)反饋。后續(xù)評(píng)審會(huì)專門討論命名問題。

提案概述：

提案引入了固定大小的 Vector 類型，其特點(diǎn)是：

• 固定大小：一旦創(chuàng)建，大小不可更改。
• 完全初始化：所有元素必須在初始化時(shí)完成初始化，不能動(dòng)態(tài)添加或移除元素。
• 非可復(fù)制性（潛在特性）：雖然 Vector 可能不可復(fù)制，但其主要獨(dú)特性在于其固定大小和初始化需求。

核心反饋與討論：

1. 初始化的特殊性：

與其他數(shù)據(jù)結(jié)構(gòu)不同，Vector 無法通過常規(guī)方法（如 init()、reserveCapacity()、append()）操作，因此初始化器需要支持直接生成元素集合。

提案中的初始化器適合 Vector 的獨(dú)特性，但可能仍不足以覆蓋更復(fù)雜的初始化模式。

2. 關(guān)于通用初始化器的建議：

當(dāng)前的初始化器雖然足夠?qū)嵱?，但建議引入更底層的初始化方法，類似于 Array 的 init(unsafeUninitializedCapacity:initializingWith:)，允許開發(fā)者通過 UnsafeMutableBufferPointer 手動(dòng)初始化。

一個(gè)更安全的方案是引入一個(gè)閉包初始化器，按元素順序初始化，同時(shí)提供對(duì)已初始化元素的訪問（例如通過未來可能支持的 Span 或 MutableSpan 類型）。這種方法可以讓初始化過程利用已有元素，實(shí)現(xiàn)排序、打亂等操作。

3. 適配性與靈活性：

提案的初始化器被認(rèn)為過于具體，可能限制開發(fā)者實(shí)現(xiàn)更復(fù)雜的功能場(chǎng)景。設(shè)計(jì)更通用的基礎(chǔ)功能有助于提升 Vector 的適配性。

總結(jié)：

提案為 Swift 引入了一個(gè)高效的固定大小數(shù)組類型，適用于需要確定大小且不可變的數(shù)據(jù)場(chǎng)景。然而，初始化器的設(shè)計(jì)需要進(jìn)一步討論，以支持更多復(fù)雜的模式和用例。評(píng)審社區(qū)還需探討是否應(yīng)該提供更通用的底層功能來滿足多樣化需求。

5. 提議修改和讀取訪問器[8]

論壇中，針對(duì)提案 修改和讀取訪問器 的討論主要集中在訪問器的命名、語義區(qū)分以及潛在的未來擴(kuò)展。以下是提案要點(diǎn)與社區(qū)反饋的總結(jié)：

提案要點(diǎn)

1. 目標(biāo)版本與時(shí)間表：

該提案未計(jì)劃納入 Swift 6.1，即使在接近的分支切割時(shí)間（2024 年 11 月 13 日）后，也不會(huì)立即生效。

2. 是否支持 async 訪問器：

當(dāng)前提案未引入異步訪問器（如異步 read 和/或 modify）。

提到這是未來可能探索的方向，同時(shí)需要考慮與現(xiàn)有功能的痛點(diǎn)進(jìn)行整合。

3. 命名建議：borrow 和 mutate 替代 read 和 modify：

提案計(jì)劃將 borrow（借用）和 mutate（變更） 用于更加基礎(chǔ)的訪問器，這些訪問器提供對(duì) self 組件的直接借用或可變借用。

而 read 和 modify 更適合描述基于協(xié)程（coroutine）的訪問器行為，它們強(qiáng)調(diào)操作的臨時(shí)性和持續(xù)時(shí)長。

4. 語義區(qū)分：

get 和 set：

表示訪問器的瞬時(shí)性和最終性，傳遞數(shù)據(jù)的所有權(quán)，而無需持續(xù)的操作。

read 和 modify：

強(qiáng)調(diào)活動(dòng)的持續(xù)時(shí)間，為某一實(shí)體提供臨時(shí)直接訪問權(quán)限，而非所有權(quán)轉(zhuǎn)移。

舉例：讀取朋友的表情或讓鎖匠修改前門，均是具有開始和結(jié)束時(shí)間的活動(dòng)，不涉及對(duì)象所有權(quán)轉(zhuǎn)移。

5. 未來方向：投影訪問器（Projection Accessors）：

投影訪問器可返回與基礎(chǔ)對(duì)象等長的借用值，使用borrow 和 mutate更符合其語義。

此類訪問器能拓展當(dāng)前存儲(chǔ)屬性的語義，并為 Swift 提供更靈活的借用模型。

反饋與討論

1. 關(guān)于詞匯選擇的細(xì)致區(qū)分：

社區(qū)成員建議 borrow 和 mutate 是否能替代 read 和 modify，但提案認(rèn)為它們有顯著的語義差異：

read 和 modify 強(qiáng)調(diào)基于協(xié)程的臨時(shí)性與操作持續(xù)時(shí)長；

borrow 和 mutate 則適合表示直接的內(nèi)存借用。

2. 詞義對(duì)比與命名合理性：

提案反駁了將 read 視為 get 同義詞的觀點(diǎn)，強(qiáng)調(diào)了兩者的語義細(xì)微差異。

參考詞典，read 和 borrow 或 modify 和 mutate 并非嚴(yán)格同義，且其語境含義差異足以避免長期混淆。

3. 生命周期與類型安全性：

基于協(xié)程的 read 和 modify 訪問器，其操作對(duì)象僅在訪問期間物化，不適合用于建模包含關(guān)系（containment）。

在處理非可逃類型（non-escapable types）時(shí)，這種差異會(huì)影響生命周期語義，成為至關(guān)重要的問題。

總結(jié):

提案中的命名設(shè)計(jì)從語義、生命周期管理與未來擴(kuò)展性等角度出發(fā)，避免了簡單的詞匯替換以確保語義精確性。當(dāng)前提案專注于基礎(chǔ)訪問器功能，但也為未來的功能（如異步訪問器與投影訪問器）留出了擴(kuò)展空間。