![[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に採用されたすべての言語変更に付けられる登録番号です。構文を1つ追加するだけでも公開手続きであるSwift Evolutionを経て、通過した提案にSE番号が与えられます。閉鎖的な印象のAppleとは対照的に、Swiftの進化はすべて公開台帳の上で行われます。
Swiftの哲学シリーズ第4回です。前3回では安全性・性能・表現力、段階的な開示、値型というSwiftの価値を扱いました。今回は、その価値を守る制度を扱います。哲学は宣言だけでは続かず、手続きがあってこそ維持されるからです。
Swift Evolutionとは — 言語変更の公開審査
2015年12月、AppleはSwiftをオープンソース化し、言語の未来を決める手続きも公開しました。舞台はGitHubのswift-evolutionリポジトリとSwiftフォーラム（forums.swift.org）です。
核心となるルールは1つです。Swiftの構文や標準ライブラリを変更するなら、誰でも例外なく提案を書き、公開レビューを通過しなければなりません。Appleのエンジニアも、Chris Lattner本人もこの手続きを迂回できません。初期にはAppleの提案がコミュニティの反対で却下され、外部開発者の提案が採用された例も数え切れません。
この手続きが守るものは何でしょうか。前3回で扱った哲学です。新機能が安全性を損なわないか、progressive disclosureを壊さないか、既存コードと一貫しているかを、提案者だけでなくコミュニティ全体が検証します。言語の一貫性が個人の好みではなく、手続きの成果になるのです。
提案の一生 — アイデアが構文になるまで
構文が言語に入るまでの道のりを、段階ごとに見ていきましょう。
第1段階、ピッチ（Pitch）。 フォーラムのEvolution > Pitchesにアイデアを投稿します。形式の制約は緩く、目的は反応を見ることです。コミュニティが代案を出し、問題点を指摘します。多くのアイデアはここで淘汰されるか、大きく形を変えます。
第2段階、提案（Proposal）の作成。 ピッチを通過したら正式な提案を書きます。Motivation、Detailed design、Source compatibility、ABI stabilityへの影響、Alternatives consideredまで必要で、なぜこの設計なのかだけでなく、なぜ他の設計ではないのかも問われます。
第3段階、実装の添付。 現在のEvolutionでは、提案に動作する実装を添えることが重要です。コンパイラで試したコードがなければレビューは始まりません。実現可能性を紙上の議論ではなくコードで証明します。
第4段階、公開レビュー。 レビューマネージャーが割り当てられ、通常1〜2週間フォーラムで公開レビューを行います。Swiftに十分重要な問題を解決するか、Swiftのfeel and directionに合うか、他言語の類似機能と比べてどうかが問われます。
第5段階、判定。 レビュー後、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）とともに審査され、1つのロードマップを形成しました。大きな機能は単独でなく提案群として入る好例です。
SE-0345 if letの省略。 if let name = nameの代わりにif let nameと書く構文です。機能は小さいものの、ピッチ段階ではif let name?などの代案をめぐって長い議論がありました。最終判定は簡潔さと明瞭さのバランスを理由に現在の構文を選びました。小さな構文にもこれほどの論証が積み重なります。
却下例も記録に残ります。 関数引数にself接頭辞を必須にする初期提案（SE-0009）はレビュー後に却下され、その理由もリポジトリに残っています。明示性の向上よりコードのノイズが増える損失が大きいと判断されたのです。却下理由の記録は、同じ議論を繰り返さずに済むことも意味します。
ここにはパターンがあります。Evolutionは何が入ったかだけでなく、何がなぜ入らなかったかも残します。言語設計の判例が蓄積されるのです。
誰が決めるのか — ガバナンス構造
手続きの最後の関門である判定は、誰が行うのでしょうか。
Swiftプロジェクトの頂点にはCore Teamがあり、言語変更の実質的な判定はLanguage Steering Groupが担います。Appleのエンジニアと外部コミュニティのメンバーで構成され、フォーラムの意見を参考にしますが、多数決では決めません。公式文書によれば、レビューは投票ではなく論証の収集です。声の大きさではなく、根拠の強さを重視します。
Appleの影響力が大きいのは事実です。コンパイラ開発者の多くはApple所属で、SwiftUIのresultBuilderのようにAppleプラットフォームの需要が提案を動かした例もあります。それでもAppleは手続き外で構文を変えられず、議論は検索可能な公開記録に残ります。server-side Swiftやembedded SwiftなどApple外の生態系が成長し、ガバナンスもワーキンググループへ分化しています。
開発者にとっての実際の利点
Evolutionを知っておくと、Swift開発者にとって明確な実利があります。
第一に、最高品質の学習資料を無料で読めます。 新構文が分からないとき、ブログより原文の提案が最良です。解決する問題、設計理由、代案が書かれ、「どう使うか」だけでなく「なぜこの形か」まで分かります。swift.org/swift-evolutionのダッシュボードでSE番号から探せます。
第二に、言語の未来を先取りできます。 フォーラムのピッチ欄は1〜2年後のSwiftの予告編です。今の注目スレッドが次のWWDCで新構文になることが繰り返されています。
第三に、参加への門戸が本当に開かれています。 レビュースレッドに利用経験を書くだけでも判定文に引用され得ます。韓国語ユーザーが文字列処理やフォーマットの提案に実用的なフィードバックを寄せるのは、想像以上に価値ある貢献です。
第四に、チームの技術判断の参考になります。 experimental feature flag、正式承認済み、upcoming featureの違いが分かれば、プロダクションコードにいつ導入するか判断できます。
まとめ
- SE-XXXXはSwift Evolutionを通過した言語変更提案の番号です。Swiftの構文変更はすべてこの公開手続きを経ます。
- 道のりは、ピッチ→代案を含む提案作成→実装添付→公開レビュー→Language Steering Groupの判定です。
- Appleも手続きを迂回できず、承認・却下の理由は公開記録として残り、言語設計の判例になります。
- 新構文を知りたいなら提案原文が最良の資料で、ピッチ欄はSwiftの未来の予告編です。
Swiftの哲学シリーズ第4回はこれで終了です。安全性・性能・表現力、段階的な開示、値型、そしてEvolutionという制度を見てきました。次回から基礎構文を深掘りし、最初はSwiftで最も身近な疑問符、オプショナルの正体を扱います。