Appleは,2017年秋に提供を予定しているSwift 4のリリースプロセスに関する詳細を発表した。今回のリリースの中心は,ソース互換性を確保しながら,言語コアと標準ライブラリが大幅に拡張されることだ。当初のロードマップにあったABI互換性は延期されることになった,と同社SwiftチームのプロジェクトリーダをChris Lattner氏から引き継いだTed Kremenek氏は説明している。
Swift 4には膨大な数の変更が含まれているため,Swift 3と完全にソース互換ではない。むしろコンパイラにおいては,Swiftが公開されて以来初めて,互換性モードである-swift-version-3
がサポートされるようになる。このモードでは,Swift 4で修正されたバグによって旧コンパイラでは許容されていた不正なコードを除けば,ほとんどのSwift 3のソースがサポートされるはずだ。-swift-version-4
モードでは,ロードマップに記載されているすべての新機能がサポートされるようになる。特に注目すべきなのは,同じSwiftコンパイラでコンパイルされたものであれば,前述したどちらのモードのフレームワークやモジュールでもリンクが可能なことだ。
Kremenek氏は,ABIの安定化が遅れたことについて,関連するファンダメンタルが正しくなる前にABIの安定化を宣言するというリスクを回避するためだ,と説明している。
言語の原作者であるChris Lattner氏は,Kremenek氏の発表について次のようにコメントしている(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032145.html)。
年間スケジュールを考慮するならば,これは現実的な判断だと思います。ABIの安定化は多くの開発者よりもAppleにとって重要なものですから,特にSwiftの長期的成功のために適切な行動を取ることの重要性を考えれば,コミュニティのニーズ(コンパイル時間の改善,コンパイラの安定化など)を優先したことは望ましいことです。
ABI安定化の完成が延期されたことは,しかしながらその開発が停止したという意味ではない。Latter氏は,ABI安定化の要件をSwift 5開発の初期段階で確定してほしい,という希望を表明している。Kremenek氏は,ABIの安定宣言に向けた残りタスクのすべてとそのステータスを一覧で示す,ABI安定化ダッシュボードの設置を間もなく発表する予定だ。
ステージ2に入るということは,変更がリリースに受け入れられるためのバーが高くなるという意味でもある。新しい構文やAPIならば,既存の構文よりも明らかに優れていなくてはならないし,ソース互換性に影響を与えるような変更であれば,既存コードに対するマイグレーションパスを用意する必要がある。すべての開発内容は,2017年夏に想定されている最終ブランチをリリースマネージャが作成するまでの間は,master
ブランチに反映される。最終ブランチが作成された以降は,選択されたフィックスのみがリリースに受け入れられるようになる。
この記事を評価
- 編集者評
- 編集長アクション