歴史。 初期のRustでは、スタック割り当てと効率的な値セマンティクスを保証するために、すべての型に静的に知られたサイズを持たせる必要がありました。スライス [T] やトレイトオブジェクト dyn Trait のような動的サイズ型（DST）が導入されると、既存のコードを壊すことなく、サイズが決まったジェネリックパラメーターとサイズが未定のものを区別するためのメカニズムが必要になりました。?Sized 構文は「緩和された」境界として採用され、ジェネリクスがデフォルトのSized要件から明示的にオプトアウトできるようにし、非サイズデータを扱わない大多数のユースケースに対して快適なデフォルトを保持しました。
問題。 暗黙的な T: Sized 制約は根本的な緊張を生み出します。これは値の操作とコンパイル時のメモリ計算を可能にしますが、関数が dyn Trait やスライスタイプを間接的でなく直接受け取ることを妨げます。この制約は、所有権のセマンティクスが求められているにもかかわらず、開発者が Box や参照を使用せざるを得ないことを強制し、静的および動的ポリモーフィズムの両方をサポートすることを目指すAPIを複雑にしています。?Sized がなければ、ジェネリックコードは具体的な型とランタイムポリモーフィックオブジェクトの両方を抽象化できず、サイズのあるバリアントとサイズのないバリアントのために強制されたヒープ割り当てや重複したインターフェースを避けられません。
解決策。 コンパイラは、?Sized で制約された型にはファットポインタを介してのみアクセスできることを強制することでこれを解決します。ファットポインタはデータポインタとランタイムメタデータ（スライスの長さ、トレイトオブジェクトのvtableを含む）の複合値です。ジェネリックが T: ?Sized を指定する場合、コンパイラは std::mem::size_of::<T>() や値による移動のような既知のサイズを要求する操作を禁止し、すべてのメモリレイアウトがコンパイル時に計算可能であることを保証します。この設計により、サイズのある型はスリムポインタを、サイズのない型はファットポインタを使用し、型システムが区別を透明に扱います。
システムモニタリングライブラリは、小さいスタック割り当てのエラーコードか、大きな動的にフォーマットされたエラーメッセージの両方をログに記録する必要がありました。最初のAPI設計は、fn log<T: Display>(error: T) でトレイトオブジェクトを拒否し、暗黙の Sized 制約が dyn Display が制約を満たすことを妨げ、動的エラーハンドリングにおける重要なエルゴノミックの障害を生み出しました。
検討された最初のアプローチは、すべてのエラータイプに Box<dyn Display> を要求し、簡単な u32 エラーコードでもヒープ割り当てに変換することでした。利点: API surface を統一し、複雑なジェネリクスなしで動的エラーの所有権を許可。欠点: 組み込みターゲットに不向きなアロケータ依存を導入し、単純で静的なエラーを扱うホットパスに測定可能な遅延を追加。
二つ目のオプションは、ジェネリック T: Display サイズの型用と、特に &dyn Display 用の2つの異なるロギングメソッドを維持することでした。利点: サイズのある型に対するヒープ割り当てを回避し、複雑なエラーに対する動的ディスパッチを正しくサポート。欠点: 大規模なコードの重複が必要で、公開APIのドキュメントが複雑になり、呼び出し側が型のサイズに基づいて正しいメソッドを選択せざるを得なくなる。
チームは次のアプローチを選択し、fn log<T: ?Sized + Display>(error: &T) を使用してサイズのある型とサイズのない型の両方に対する参照を受け入れました。この解決策は、単一の一貫したAPIエントリポイントを維持し、必須のボックス化を回避することで no-std 環境をサポートし、二重メソッドアプローチと比較してランタイムのオーバーヘッドがゼロになるため選ばれました。ジェネリック実装は、サイズのある型に対して元の単一のバージョンと同じ機械コードにコンパイルされ、vtableディスパッチを介してトレイトオブジェクトを正しく扱いました。
その結果、クレートはマイクロコントローラとサーバー全体に成功裏に展開され、数百万の異種エラーイベントを割り当てオーバーヘッド無しで処理しました。統一されたインターフェースにより、開発者は &ConcreteError と &dyn Error の両方をシームレスに渡すことができ、?Sized が異なる展開ターゲットに対して真のゼロコストポリモーフィズムを可能にすることを示しました。
なぜ、T: ?Sized 型の値を返すことができないのか？
値を返す関数は、それらの値をレジスタまたはスタックに配置する必要があり、呼び出し規約に必要な正しいコードを生成し、適切なスタックスペースを予約するためにコンパイル時に知られたサイズが必要です。?Sized 型、例えば [i32] や dyn Debug はランタイムで決定されるサイズを持つため、コンパイラはABIのために必要な固定サイズの返却命令シーケンスを生成できません。ポインタ型 (Box<T>, &T) のみが静的に知られたサイズを持ち、そのためサイズ未定データの唯一の合法的な返却型となり、基本的に ?Sized ジェネリックを「値」型として動かせることができる「ビュ」型に制限します。
?Sized は参照に対するトレイト実装の整合性ルールとどのように相互作用するか？
T: ?Sized の場合、&T に対するトレイトの実装は、自動的にファットポインタ（&[i32] や &dyn Trait のような）に適用されます。候補者は往々にして、impl Trait for &T where T: ?Sized がサイズのあるデータとトレイトオブジェクトの両方を扱うブランケット実装を定義するために重要であり、サイズのある型のみに適用される impl Trait for T where T: Sized とは異なることを見逃します。この区別は、オーバーラップする実装が Rust の孤児ルールに違反しないように、型階層全体で整合性を確保するために重要です。
所有権セマンティクスを除いて、Box<dyn Trait> と &dyn Trait のメモリ表現を区別するものは何か？
両者はファットポインタ（ポインタ + vtable）を使用しますが、Box<dyn Trait> はアロケーションを所有し、解放目的のためにvtableポインタを格納しますが、&dyn Trait は単にデータを観測します。重要なのは、Box<T> の場合、T: ?Sized が動的サイズ解放を処理するためにvtableに格納されたサイズを使用することを必要とするのに対し、参照はそのような責任を持たないことです。初心者は、Box がスタック上に存在できないサイズのない型のヒープ割り当てを可能にする一方、参照は単に既存のメモリを借用するため、Box が関数から所有される非サイズデータを返すために不可欠であることを見落としがちです。