質問への回答
Swiftの同時性モデルは、バージョン6.0で大幅に強化され、モジュール境界を越えて拡張される厳格なデータアイソレーション要件が導入されました。厳格な同時性チェックでコンパイルされたモジュールが、@preconcurrencyでマークされたレガシーモジュールに呼び出すとき、コンパイラは静的解析だけに頼って安全性を保証することができません。なぜなら、呼ばれる側の実装はactorのアイソレーション保証が導入される前のものである可能性があるからです。このギャップを埋めるために、Swiftは関数の型情報内およびウィットネスタブルにアイソレーション要件をメタデータとして埋め込んでおり、呼び出し規約やシンボルマングリングを変更することなく、ABIの安定性を保っています。実行時には、生成されたコードがswift_task_isCurrentExecutorintrinsicを使用して動的なチェックを実行し、現在のタスクが必要なグローバルactorのシリアル実行者で実行されていることを確認することで、続行します。チェックが失敗すると、タスクは非同期で正しい実行者にキューイングされるか、ビルド構成に応じて診断クラッシュがトリガーされます。
生活からの状況
金融テクノロジーチームは、背景スレッドで重い統計計算を行い、時折完成ハンドラーを通じてUIの更新を投稿するレガシー分析SDK（モジュールB）を管理していました。新しいコンシューマーバンキングアプリ（モジュールA）でSwift 6を採用するにあたり、すべてのUIの更新がMainActor上で発生することを保証する必要がありました。彼らはSDK全体を即座に書き換えることなく、アイソレーション境界の問題を解決するために3つのアプローチを考えました。
最初のオプションは、SDKを同期的に書き換えてSwift 6のactorsとSendable型を全体に採用させることでした。これにより、コンパイル時の安全性とランタイムオーバーヘッドゼロが提供されますが、エンジニアリングコストが高く、3ヶ月と見積もられ、重要な計算ロジックに高い回帰リスクをもたらしました。2つ目のオプションは、モジュールAの呼び出しポイントでSDKのコールバックを手動でDispatchQueue.main.asyncでラップすることです。このアプローチは明示的でSDKの変更を必要としませんが、もろく散発的なボイラープレートを生み出し、新しい開発者が機能を追加した際に見逃してデータ競合を引き起こす可能性がありました。3つ目のオプションは、SDKの公開インターフェースに**@preconcurrency**アノテーションを付け、MainActorアイソレーション要件と組み合わせることでした。
チームは3番目の解決策を選択し、レガシーコールバックに@preconcurrency @MainActorを注釈しました。これにより、モジュールAはこれらのメソッドを呼び出す際に、Swiftランタイムが移行期間中に実行者コンテキストを動的に検証することを保証しました。背景スレッドがUIコールバックを呼び出そうとするなどの違反が発生すると、アプリはデバッグビルドで明確な診断とともに即座にクラッシュし、開発者はスレッド仮定を段階的に特定して修正することができました。SDKが厳密な同時性に完全に移行した後、彼らは静的アイソレーションを独占的に強制するために**@preconcurrency**を削除し、ランタイムアイソレーションチェックのない、スレッド安全性が保証されたコードベースを実現しました。
候補者が見逃すことが多い点
@preconcurrencyがABIにおける関数のマングルされたシンボル名にどのように影響し、これが動的リンクにとってなぜ重要であるのか？
@preconcurrencyは、アイソレーション要件がシンボル自体ではなく、型メタデータとウィットネスタブルにエンコードされているため、関数のマングルされたシンボル名や低レベルの呼び出し規約を変更しません。この設計はABIの安定性にとって重要であり、ライブラリの著者が既存の公開APIにactorアイソレーションを追加しても、以前にコンパイルされたクライアントとのバイナリ互換性を壊さないことを可能にします。動的チェックは、メタデータに基づいてコンパイラによって呼び出しポイントやエントリポイントで注入され、古いバイナリが新しいアイソレーション対応ライブラリにシームレスにリンクできることを保証します。
グローバルアクターのsharedインスタンスがletとして宣言される場合とvarとして宣言される場合の違いは何であり、これが実行者のユニーク性にどのように影響しますか？
GlobalActorプロトコルは、基盤となるactorインスタンスを返す静的なsharedプロパティを要求し、このプロパティはプロセス全体で一意の単一シリアル実行者を保証するためにlet定数として宣言されなければなりません。もしsharedがvarであれば、実行者は理論的にはランタイムで交換される可能性があり、グローバルactorがすべてのアイソレートされた操作に対して単一のシリアルキューを提供するという基本的な不変条件を違反することになり、データ競合を引き起こし、アイソレーション境界を破る可能性があります。Swiftコンパイラは、sharedが静的な不変プロパティであることを要求することでこれを強制し、swift_task_isCurrentExecutorが常に一貫したシングルトン実行者オブジェクトと比較されることを保証します。
関数がグローバルアクターにアイソレーションされている場合、なぜコンパイラは同じアクター内から呼び出されるときでも実行者へのホップを生成することがあるのか、そしてisolatedパラメータ修飾子はこれをどのように最適化するのか？
コンパイラは、呼び出し元がターゲットのグローバルactorの実行者で既に実行されていると静的に証明できない場合、実行者ホップまたは少なくともランタイム検証を生成します。これは、モジュール境界を越えたり、アイソレーション情報が消去された存在性型を介して呼び出す際に一般的に発生します。この保守的なアプローチは安全性を確保しますが、同期のオーバーヘッドを伴います。開発者は、呼び出し元のアイソレーションコンテキストを引数として明示的に渡すisolatedパラメータ修飾子（例：func process(isolation: isolated MainActor = #isolation)）を使用することで、これを最適化できます。これにより、コンパイラはランタイムチェックとホップを省略でき、呼び出しが同じ実行者にあることを証明した際は、文脈切り替えコストのない直接の関数呼び出しとなります。