![[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 究竟是什么。