この記事の要点
- Core Team が各ワークグループと開発者に調査を行い、2023 年にかけて Swift プロジェクト全体が注力する領域をまとめた記事です。多数のリポジトリやフォーラムに散らばっている取り組みの全体像を、コミュニティが俯瞰できるようにすることを目的としています。
- コミュニティ運営は、Core Team が直接多くの領域を見る中央集権的な体制から、Language / Website / Documentation / C++ Interoperability といった専門ワークグループに責任を委ねる体制へと再編が進められています。
- 言語面では、Concurrency・Generics・Ownership・Macros・C++ 相互運用の 5 領域に集中し、あわせて来たる Swift 6 言語モードに向けた変更の確定を計画しているとされています。ビルドシステム連携やパッケージレジストリ、実装面の改善も挙げられています。
- ここに書かれた内容はいずれも特定リリースへの確約ではなく、計画や優先順位は今後変わりうる点が明記されています。
注力する領域
コミュニティ運営の再編
Swift は長らく Core Team が多くの領域を直接監督する中央集権的な構造でしたが、専門ワークグループにより多くの責任を委ねる再編が始まっています。記事の時点で挙げられているワークグループは次のとおりです。
- Language Workgroup — 言語と標準ライブラリの進化
- Website Workgroup —
swift.orgの Web コンテンツの管理 - Documentation Workgroup — ドキュメントツール・ライブラリ開発の組織化
- C++ Interoperability Workgroup — C++ との相互運用改善に向けた言語 Proposal の育成
これらは既存の Swift on Server ワークグループや Diversity ワークグループに加わるもので、自分の関心領域のワークグループに参加することで貢献しやすくなります。プラットフォーム横断での使い勝手向上に特化したものなど、さらにいくつかのワークグループ新設も検討されています。あわせて、プロジェクトの基盤インフラを支えてきた Mishal Shah が Core Team に加わることも発表されました。
言語開発の 5 領域
Language Workgroup は次の 5 つの主要領域での前進に注力します。
- Concurrency:
Sendableとアクターによる厳格なデータ隔離の言語サポートを完成させます。グローバル変数や一部のクロスアクター呼び出しに残るスレッド安全性の穴をふさぐとともに、厳格な isolation に伴う使い勝手の問題を解決する言語機能(限られた状況で non-Sendable値を isolation domain 間で移動できるようにするなど)の追加も検討します。 - Generics: 複数年がかりの大型機能である variadic generics の本格的な作業を開始します。まずはコア言語モデルの設計とコンパイラ・ランタイム基盤の実装に注力し、初期マイルストーンとしてタプル型が要素に応じて
Equatableなどのプロトコルに条件付きで適合できるようにすることが挙げられています。 - Ownership: メモリ上の値の所有権をプログラマが明示的に制御する機能(暗黙のコピー禁止、所有権の移動、コピーを伴わない明示的な「borrow」)を開発します。あわせて non-copyable 型の基本サポートを追加し、「unsafe」な構文の性能と標準ライブラリの安全性を両立する新しいデータ操作の手段を提供します。
- Macros: 豊かなライブラリや DSL の構築を後押しする手続き的マクロの基礎を開発します。まずはマクロが Swift で何を実現でき、どう言語に組み込まれるかを示す vision ドキュメントの作成から始めるとされています。
- C++ interoperability: C++ の API を Swift から、Swift を C++ から使えるようにする設計の vision ドキュメントを整備し、現在プロトタイプ段階にある双方向の相互運用機能の安定化を進めます。
これらに起因する言語変更は、通常どおり Swift Evolution プロセスでピッチ・レビューされます。あわせて Language Workgroup は、Proposal の管理プロセスや、Proposal の著者・レビュアー向けガイドラインの詳細な文書化にも取り組みます。さらに、来たる Swift 6 言語モードに向けた言語変更の確定も計画されています。言語モードは、既存コードのソース互換性を壊さずに言語を前進させるために定期的に導入される仕組みです。
ビルドシステム連携とパッケージレジストリ
コンパイラ開発チームは、コンパイラとビルドシステムの連携を改善します。明示的なモジュールロードへの移行、モジュール依存関係の探索とコンパイルの分離、リンク時依存関係の発見によりビルドシステムが直接リンカを呼び出せるようにするなどが含まれます。自動生成される module interface やバイナリモジュール基盤の品質も高め、ライブラリ作者が API をより確実に提供できるようにします。
Swift Package Manager では、コミュニティと連携してオープンソースのパッケージレジストリサーバー実装の作業を開始します。ソース管理ベースのエコシステムからレジストリベースへ移行し、セキュリティと信頼性を高めることが狙いで、Swift Package Index のようなコミュニティ運営プロジェクトとも協力するとされています。
実装面の改善
コンパイラ開発者は実装レベルでも複数の改善に注力します。代表的なものは次のとおりです。
- C++ 実装と機能的に同等で、純粋な Swift で書かれた Swift パーサの開発(将来的に C++ パーサを置き換える)
- result builder の型チェック性能の改善
- コード補完や Quick Help・Jump to Definition といったツールの信頼性向上
- 変換 thunk の削減や型レイアウトのコンパクトな表現の解釈による生成コードの削減
- オブジェクトの lifetime・コピーに関する予測可能な最適化のための SIL オプティマイザ拡張
- C++ 実装に代わる、より正確で簡潔な Swift 製の手続き間 side-effect・escape 解析
このほか、Documentation・Website・Swift on Server の各ワークグループの計画や、AI/ML 向けの Differentiable Swift(堅牢性・性能の改善、KeyPath の性能向上など)の取り組みも紹介されています。
参加・利用者への影響
この記事は、Swift プロジェクトの今後の方向性を知りたいすべての人に向けたものです。掲載された計画はいずれも特定リリースへの確約ではなく、優先順位は変わりうる点に注意が必要です。言語変更は Swift Evolution プロセスを通るため、関心のある領域についてはフォーラムのディスカッションやピッチ、Proposal レビューに注目するとよいでしょう。各項目についての質問やフィードバックは、該当するワークグループやこの記事のフォーラムスレッドへ寄せる形が案内されています。