Swiftは、回復力のある構造体にストアプロパティを追加する際にABIの安定性を維持するために、どのような特定のメタデータ構造を使用していますか？

質問への回答。

Swiftは、回復力のある構造体のABI安定性を維持するために、フィールドオフセットをランタイムメタデータに保存し、クライアントバイナリ内で即時のオフセット値としてハードコーディングするのではありません。モジュールが非凍結構造体をエクスポートすると、コンパイラは型のメタデータ内に埋め込まれたフィールドオフセットテーブルを通じてストアプロパティにアクセスするコードを生成します。この間接アクセスにより、ライブラリの著者は将来のバージョンで新しいストアプロパティを追加しても、古い構造体レイアウトに対してコンパイルされた既存のバイナリを無効にせずに済みます。一方、@frozen構造体は直接オフセット計算を利用し、メモリアクセスが速くなりますが、レイアウトを永久に凍結します。トレードオフとして、オフセットテーブルからの追加のメモリロードによるわずかなパフォーマンスコストが発生します。

生活からの状況

数百のクライアントアプリケーションに配布されるコアAnalytics SDKを設計していると想像してください。SDKは最初に2つのフィールドを持つConfig構造体を定義しています：apiKeyとenvironment。リリースから6か月後、製品要件によりretryPolicyとtimeoutIntervalフィールドをこの構造体に追加する必要があります。

// AnalyticsSDK (モジュールA) - 最初にコンパイルされた
public struct Config {
    public let apiKey: String
    public let environment: String
    // @frozenなしでv2.0に新しいフィールドを追加:
    // public let retryPolicy: RetryPolicy
}

もしこの構造体が**@frozenであった場合、この変更は既存のクライアントアプリをクラッシュさせてしまいます。なぜなら、構造体のサイズとフィールドオフセットをコンパイル時にハードコーディングしていたからです。私たちはこの進化問題を解決するために三つのアプローチを検討しました。最初のアプローチは、構造体をクラスに変換し、ヒープ割り当てとポインタの安定性を活用することでした。これによりABIの互換性は保持されましたが、不必要な参照カウントのオーバーヘッドと参照セマンティクスが導入され、値型の不変性保証が破られました。第二のアプローチは、並行してConfigV2構造体を配布し、元のものを非推奨にすることを提案しました。これにより互換性は保持されましたが、API surfaceが分断され、開発者が明示的に移行する必要がありました。第三のアプローチは、@frozen属性を削除した回復力のある構造体**を採用し、コンパイラがメタデータの照会を通じて間接的なフィールドアクセスを生成できるようにしました。

私たちは第三の解決策を選びました。なぜなら、それがパフォーマンスと将来の柔軟性のバランスを取るからです。クライアントバイナリは再コンパイルなしで機能し続け、ランタイムにSDKのメタデータからフィールドオフセットを動的に照会しました。その結果、SDKのバージョン間での設定構造のシームレスな進化が実現しましたが、頻繁にアクセスされる設定フィールドは別途ローカルにキャッシュすべきであることを文書化しました。

候補者が見逃すことが多いこと

Swiftは、定義モジュールをインポートするクライアントコードをコンパイルする際、回復力のある構造体のサイズとアライメントをどのように決定しますか？

回復力のある構造体に対してコンパイルする際、Swiftは新しいフィールドが後で追加される可能性があるため、具体的なサイズやアライメントを静的に知ることはできません。代わりに、コンパイラはランタイムで型メタデータに関連付けられたValue Witness Table（VWT）を参照するコードを生成します。VWTは、サイズ、アライメント、ストライド、および破棄のための関数を提供し、クライアントは構造体のレイアウトに対する事前の知識なしに正しいスタックスペースやヒープメモリを割り当てることができます。

回復力のある列挙体のスイッチングには@unknown default句が必要なのはなぜですか？新しいケースが追加された場合、内部では何が起こりますか？

回復力のある列挙体は、インポートモジュールに対して完全なケースリストを公開せず、デフォルト句なしでは網羅的なスイッチングを防ぎます。ライブラリの著者が新しいケースを追加すると、列挙体のメタデータは新しいタグ値を含むように更新されます。@unknown defaultでコンパイルされたクライアントコードは、ランタイムでこの未知のタグをデフォルトブランチにフォールスルーすることで処理できますが、凍結された列挙体は認識されないタグでトラップします。なぜなら、スイッチステートメントがフォールバックのないジャンプテーブルとしてコンパイルされるからです。

@inlinable属性はモジュール間でどのような特定の最適化を提供し、なぜそれが回復力を壊すのですか？

@inlinableは、関数またはメソッドの本体をインポートモジュールのコンパイラに公開し、モジュール間のインライン化とデッドコードの排除を可能にします。これにより、クライアントコンパイラが実装の詳細を直接クライアントバイナリに埋め込むため、回復力が壊れます。ライブラリの著者が後に実装を変更した場合、クライアントは古いインラインコードを引き続き使用するため、内部データ構造が変更された場合、微妙な動作の違いまたはクラッシュを引き起こす可能性があります。