![[Swift 哲學 #4] Swift Evolution 與 SE-0296 封面圖](/assets/images/posts/d92caedf-939a-44c8-bad7-261591745177/1.jpg)
閱讀 Swift 文章或版本資訊時，常會看到 SE-0296、SE-0345。async/await 對應 SE-0296，而if let name縮寫語法對應 SE-0345。這些編號究竟是什麼？
簡單說，它們是所有進入 Swift 的語言變更之登記編號。Swift 即使新增一個語法，也必須經過公開流程 Swift Evolution；通過流程的提案會取得 SE 序號。與 Apple 封閉的形象正好相反，Swift 的演進完全建立在公開帳冊上。
這是 Swift 哲學系列第 4 篇。前三篇談過 Swift 守護的價值：安全性、效能與表達力、漸進式揭露，以及值型別；本篇則討論守護這些價值的制度。哲學不能只靠宣告維持，必須有流程。
什麼是 Swift Evolution — 語言變更的公開審查
2015 年 12 月，Apple 開放 Swift 原始碼，也一併公開決定語言未來的流程。舞台就是 GitHub 的 swift-evolution 儲存庫與 Swift 論壇（forums.swift.org）。
核心規則只有一個：要變更 Swift 語法或標準函式庫，任何人都必須撰寫提案並通過公開審查。Apple 工程師，甚至 Chris Lattner 本人，都不能繞過流程。早期 Apple 的提案曾因社群反對而遭駁回，外部開發者的提案則有無數進入語言。
這套流程守護的是什麼？正是前三篇談過的哲學。新功能是否損害安全性、破壞漸進式揭露、與既有程式碼保持一致，不由提案者單獨決定，而由整個社群驗證。語言的一致性成為流程的產物，而非個人偏好。
提案的一生 — 從想法到語法
以下逐步追蹤一個語法進入語言的旅程。
第一階段，Pitch。 將想法發表在論壇的 Evolution > Pitches。形式限制寬鬆，目的是測試反應。社群會提出替代方案並指出漏洞，多數想法會在此被淘汰或大幅改變。
第二階段，撰寫 Proposal。 Pitch 通過後撰寫正式提案。模板包含 Motivation、Detailed design、Source compatibility、ABI 穩定性影響，以及 Alternatives considered。它要求說明的不只是為何採用此設計，也包括為何不是其他設計。
第三階段，附上實作。 目前 Evolution 的慣例要求提案附帶可運作的實作。沒有實際接入編譯器測試過的程式碼，就不會開始審查。可行性必須用程式碼證明，而不是在紙上爭論。
第四階段，公開審查。 指派審查管理者，通常在論壇進行 1～2 週的公開審查。公告會列出問題：是否解決足夠重要的問題、是否符合 Swift 的方向，以及與其他語言的類似功能相比如何。
第五階段，決議。 審查結束後由 Language Steering Group 作出結論。結果為 Accepted、Returned for revision 或 Rejected，且一定附上理由。通過後確定 SE 編號，實作會隨特定 Swift 版本發布。
從實際案例看流程的分量
看看幾個知名案例，了解流程實際如何運作。
SE-0296 async/await。 這是 Swift 並行處理的起點。方向源自 Chris Lattner 2017 年的 Concurrency Manifesto，經過提案、審查與核准，花了數年才進入 Swift 5.5。期間與 actor（SE-0306）、結構化並行處理（SE-0304）等提案一同審查，形成一份路線圖。大型功能通常以提案群組進入語言。
SE-0345 if let 縮寫。 這是用if let name = name取代if let name的語法。功能雖小，Pitch 階段卻曾長時間爭論if let name?等替代寫法。最終決議以簡潔與清晰的平衡選擇目前語法。即使細小語法，也會累積如此充分的論證。
駁回案例也會留下紀錄。 早期要求函式引數強制加上 self 前綴的提案（SE-0009）在審查後遭駁回，理由至今仍在儲存庫中。社群認為增加明確性的收益，不足以抵銷程式碼噪音的損失。記錄駁回理由，也能避免重複相同爭論。
這些案例呈現出一個模式：Evolution 不只記錄什麼被納入，也記錄什麼沒被納入及原因。語言設計的判例就這樣累積。
誰來決定 — 治理結構
流程最後的決議由誰作出？
Swift 專案最上層是 Core Team，語言變更的實質決議則由 Language Steering Group 負責。成員包括 Apple 工程師與外部社群成員，會參考論壇意見，但不是以多數決決定。官方文件稱，審查不是投票，而是蒐集論證；目標是讓證據充分的一方勝出，而不是聲音最大的一方。
Apple 的影響力確實很大。多數編譯器開發者隸屬 Apple，Apple 平台需求也曾推動提案，例如 SwiftUI 所需的 resultBuilder。但即使是 Apple，也不能在流程外修改語法，而且所有討論都會留下可搜尋的公開紀錄。隨著 server-side Swift、embedded Swift 等 Apple 平台外的生態系成長，治理也逐漸分化為工作小組。
對開發者的實際好處
了解 Evolution，對 Swift 開發者有明確的實際好處。
第一，免費取得最高品質的學習資料。 新語法看不懂時，提案原文比部落格更好。它說明要解決的問題、設計依據與替代方案，讓你不只知道怎麼用，也知道為何如此設計。可在 swift.org/swift-evolution 儀表板用 SE 編號查找。
第二，提前看見語言的未來。 論壇的 Pitch 區就像 1～2 年後 Swift 的預告片。現在熱門的討論串，反覆成為下一屆 WWDC 發布的新語法。
第三，參與的大門確實敞開。 只要在審查討論串分享使用經驗，就可能被引用於決議。韓語使用者對字串處理或格式化提案提供實際回饋，是比想像中更有價值的貢獻。
第四，可作為團隊技術決策的參考。 分辨 experimental feature flag、正式核准功能與 upcoming feature，就能判斷何時導入正式環境程式碼。
總結
- SE-XXXX 是通過 Swift Evolution 的語言變更提案編號。Swift 的所有語法變更都要經過這項公開流程。
- 流程是 Pitch → 撰寫提案（含替代方案審查）→ 附上實作 → 公開審查 → Language Steering Group 決議。
- Apple 也不能繞過流程；核准與駁回的理由都會成為語言設計的公開判例。
- 想了解新語法時，提案原文是最佳資料；Pitch 區則是 Swift 未來的預告片。
Swift 哲學系列第 4 篇到此結束。我們看過安全性、效能與表達力、漸進式揭露、值型別，以及 Evolution 這套制度。接下來將深入基礎語法，第一個主題是 Swift 最常遇到的問號：Optional 的真相。