Swift 3のABI安定化が見送りへ

Swift言語の原作者であるAppleのChris Lattner氏が先日，Swift Evolutionメールリストで，当初Swift 3の目標のひとつとされていたABIの安定化を見送る予定であることを発表した。

Lattner氏自身のことばでは，

開始時に立てた崇高な目標の中のいくつかが，リリースに間に合わない見込みになりました - 標準ライブラリのABIをロックダウンする上では欠かせない，最も重要なジェネリクス機能もその中に含まれています。

その結果，ABIの安定化は，Swift EvolutionリポジトリのReadMeから削除されることになった。

元々のReadMeに記されていたように，ABIの安定化とは，Swiftの将来のバージョンでコンパイルされたアプリケーションやライブラリと，Swift 3.0でコンパイルされたコードとのインタラクションを可能にするためのものだ。つまりABIが安定化すれば，たとえソース言語が変更されても，バイナリレベルでの互換性を一定のレベルで保証することにより，サードパーティがバイナリライブラリを出荷しやすくなるのである。さらに，ABIが安定的になれば，Xcodeで作成したiOSとOS X用アプリが現在そうであるように，バイナリにSwift標準ライブラリを添付して出荷する必要もなくなる。

Lattner氏はさらに，この機能に関して行われた議論の内容を公開し，同機能を言語に追加する作業の着手が2016年8月頃になる見込みであることを明らかにした。Swift 3.1と4.0のどちらに安定化APIが提供されるのか，現時点ではまだ明確ではないが，最優先の機能のひとつになることを氏は期待している。

Swift 3のために当初考えられていた目標の大部分が放棄されることについて，いくつかの不満の声もあがっている。その他には，Swift 3の当初の目標設定が，オープンソース化されたごく初めの時期に定義されたものであることを強調する意見もある。コミュニティからの要望の声がSwiftの開発上の重点を，ABIの安定よりも先に，より優れた定義を必要とするような言語の領域へと向かわせることになった，という指摘だ。加えて，AppleのエンジニアであるGreg Parker氏が言うように，OS XやiOSのアーキテクチャ変遷の歴史が示すように，ABIは一度定義されてしまうと変更が非常に難しくなる。その例として氏は，Objective CのABIが，おもにスケジュール上のプレッシャによって，故意ないし偶然の欠陥を抱えたことを指摘している。具体的には，BOOLが本来のbooleanでなくキャラクタ値であること，“ゼロコスト”例外に代えてGCCの遺産であるsetjmp-longjmp例外を選択したことなどだ。氏の全体的な結論は，

Swift 3でSwift ABIの安定化を急げば，故意ないし偶然による問題を抱えるようになることは，火を見るよりも明らかです。[...] 妥当なものを手に入れるまで時間を確保できるならば，それは得難い贅沢でしょう。