Any トレイトは、Rust の開発初期に、主にコンパイル時の型情報が利用できないエラーハンドリングやデバッグシナリオ向けに動的型付け機能を提供するために導入されました。その設計は、他の言語（例えば C++ の typeid や Java の instanceof）に見られる類似の概念を反映していますが、Rust の所有権モデルは独自の制約を課しています。'static 要件は、型消去された参照がそれが説明するデータよりも長生きしないようにする必要から生じ、ガベージコレクションのない言語において使用後解放エラーを防ぐ役割を果たします。
'static 制約がない場合、Any として型消去されたタイプは、有効期限が制限されたスタックローカルデータへの参照を含む可能性があります。もし Any トレイトオブジェクトがそのスタックフレームを超えて生き残れば、ダウンキャストやデリファレンスが解放されたメモリにアクセスすることになります。Any は V テーブルと型消去を介して操作するため、コンパイラはダウンキャスト時にライフタイムを検証できません。'static 制約は、型がすべてのデータを所有しているか、静的参照のみを保持しているという保守的な保証として機能し、消去境界を越えてメモリの安全性を確保します。
Any トレイトの定義 trait Any: 'static は、Rust のトレイト境界システムを利用して、この制約をコンパイル時に強制します。非静的参照を含まない型のみが Any を実装できるため、&dyn Any や Box<dyn Any> がプログラム全体の有効性を維持することが保証されます。これにより、スコープを抜けても基盤となるデータが無効化されないことが確保されるため、安全なダウンキャストが行えます。
私たちは、スクリプトがコアエンジンに任意のデータを返すイベントハンドラーを登録できるゲームエンジンのプラグインシステムを構築していました。エンジンは、異なるサブシステムによる後処理のために、異種のキューにこれらの戻り値を保存する必要があり、型消去が必要でした。しかし、いくつかのスクリプトバインディングは、スクリプトの実行コンテキスト内の一時的なローカル変数への参照を返そうとし、スクリプトフレームが完了するとダングリングになる可能性がありました。
解決策 1: ライフタイムパラメータを持つカスタムトレイト
1つのアプローチは、ライフタイムパラメータ付きの関連型を持つカスタムトレイト PluginResult を作成することで、エンジンがトレイトオブジェクトを介してライフタイムを追跡できるようにするものでした。これは、借用データを許可することで柔軟性を提供することが期待されましたが、プラグインAPI全体で複雑なライフタイム注釈が必要となるため、すべてのプラグイン作者が高度な Rust のライフタイムメカニクスを理解する必要があり、受け入れ難い学習曲線と第三者コードの微妙なライフタイムバグのリスクが増加しました。
解決策 2: Unsafe ライフタイムの変換
もう1つの解決策は、データを格納する際にライフタイムを変換するために unsafe コードを使用することを提案しました。これにより、エンジンが全ての参照をソーススコープが終了する前に落とすことを約束するものでした。これは希望する API の使いやすさを可能にしましたが、メモリ安全性の負担を完全にエンジン開発者に課すことになりました。参照の出所を追跡する際のミスは、悪用可能な使用後解放の脆弱性を引き起こし、Rust の安全保障を違反し、コードベースの監査を困難にしました。
私たちは、すべてのプラグイン戻り値が 'static 制約を持つ Any を実装することを義務付け、スクリプト作成者が所有データまたは Arc でラップされた共有状態を返すことを強制しました。この決定は、エンジンのイベントキューがデータを安全に保持し、非同期に処理できる保証のために、ゼロコピー参照の理論的なパフォーマンス利点をいくつか犠牲にしました。その結果、公開インターフェースに unsafe コードが含まれない堅牢なプラグインAPIが生まれましたが、以前は一時的な借用に依存していた型のためにシリアライズレイヤーを追加する必要がありました。
なぜ Any は、トレイトオブジェクトを作成するために使用される参照のライフタイムだけでなく、'static** を必要とするのですか？**
Any トレイトは、コンパイル時に型情報を消去して V テーブルを生成するため、プロセス中にすべてのライフタイムデータが失われます。&dyn Any を作成すると、コンパイラはトレイトオブジェクトに元のライフタイム 'a をエンコードできません。'static を必要とするのは、基盤となる型がダングリングポインタを含まないことを、ランタイムのライフタイム追跡なしで保証する唯一の方法です。もし Any が短いライフタイムを受け入れた場合、V テーブルポインタ自体がライフタイムメタデータを持つ必要があり、これには Rust が依存型を実装するか、実行時の借用チェックが必要になり、言語のゼロコスト抽象モデルが根本的に変わることになります。
元の型が非静的参照を含んでいるとき、Box<dyn Any> は 'static 制約とどのように相互作用しますか？
struct Wrapper<'a>(&'a str) のような型は、'static トレイト境界を満たさないため、Any を実装できません。その結果、Wrapper<'a> インスタンスから Box<dyn Any> を作成できません。候補者は、値のボックス化がそのライフタイムを延ばすと誤解しがちですが、Box はヒープ上の割り当てのみを所有し、その割り当て内のフィールドによって参照されるデータを所有するわけではありません。参照されるデータがスタックローカルである場合、外側の構造体をヒープに移動しても参照のライフタイムは延びないため、コンパイラは Box<dyn Any> への変換を正しく拒否します。これにより、ヒープに割り当てられたボックスが、参照されたデータを含むスタックフレームを超えて生き残るシナリオを防ぎます。
カスタム Any トレイトを実装し、unsafe コードと手動のライフタイム追跡を使用して 'static 要件を緩和できますか？
技術的には、ライフタイムをトランスミュートし、カスタム V テーブルを使用することで可能ですが、そのような実装は無効です。なぜなら Rust のトレイトシステムと借用チェッカーは、ダウンキャスト地点でライフタイムの不変条件を検証できないからです。ランタイムのライフタイムを追跡する平行な型システムを実装し、アクセスごとに元のスコープがまだ存在することを確認する必要があります。このアプローチは基本的にガベージコレクターまたは参照カウントシステムを再実装することになり、Rust のコンパイル時の保証を失うことになります。さらに、任意の unsafe 実装は、Any の不変条件を期待する標準ライブラリコンポーネントと不適切に相互作用し、std::any::Any トレイトオブジェクトと混合されたときに未定義の動作を引き起こすことになります。