歴史: Const genericsはRust 1.51で安定化し、型を原始整数型の定数値によってパラメータ化できるようにし、[T; N]のようなジェネリック固定サイズの配列を可能にしました。設計段階で、言語チームはconstジェネリックパラメータを構造的等価性と決定論的なコンパイル時評価を示す型に厳格に制限しました。この制限により、f32、f64、および&strリテラルは、全順序に違反したり、ランタイムメモリアドレスに依存したりするため除外されました。
問題: 浮動小数点型の根本的な問題は、NaN（Not-a-Number）が存在することで、反射的等価性を破り（NaN != NaN）、コンパイラがモノモルフォシス中に型のアイデンティティを信頼できないためです。文字列リテラル（&str）については、そのファットポインタ表現（アドレス + 長さ）とデータセグメント内の特定のメモリアドレスへの依存が問題であり、これはコンパイルユニットやクレート間で決定論的ではありません。型システムは、**MyStruct<1>とMyStruct<1>**が常に同一の型を指すことを必要とし、constパラメータの等価性はコンパイル時にビットワイズまたは構造比較を通じて決定可能である必要があります。
解決策: Rustコンパイラは、HIR（高レベル中間表現）の降下と型チェック中に、StructuralPartialEq（不安定）のような内部トレイトを通じてこれらの制約を強制します。constジェネリックパラメータに遭遇したとき、コンパイラはタイプが整数、bool、またはchar、または構造的等価性をサポートすることを明示的にマークされたユーザー定義型であることを確認します。浮動小数点型はその等価性が反射的でないため拒否され、&strのような参照は生存期間と間接性を導入し、constジェネリックに必要な**'static**コンテキストで調和できないため拒否されます。モノモルフォシス中、コンパイラはconst式を評価し、構造的等価性を使用して同一のインスタンス化をマージし、型安全性を保証します。
// 有効: usizeは構造的等価性を持つ struct Matrix<const N: usize> { data: [[f64; N]; N], } // 無効: f64は全順序が欠如している（NaNの問題） // struct Physics<const G: f64>; // エラー: 浮動小数点型はconstジェネリックに使用できません // 無効: &strは間接性と生存期間の複雑さを持つ // struct Label<const S: &str>; // エラー: `&str`はconstジェネリックパラメータの型として禁止されています
あなたは高頻度取引エンジンを設計しており、金融商品の契約仕様のためにコンパイル時定数パラメータを持つ必要があります。たとえば、ティックサイズ（例: 0.25 USD）や乗数係数です。最初の設計は、これらの正確な十進数値を型システムに直接エンコードするためにf64 constジェネリックを使用し、これらの定数のランタイムストレージを排除し、価格計算のコンパイル時最適化を可能にしようとしました。
考慮されたアプローチの1つは、f64ビットをu64に変換してそれをconstパラメータとして使用し、実装内で再度変換するというものでした。しかし、これは危険であることが判明しました。ビットワイズに同一の浮動小数点数は符号付きゼロ（+0.0対**-0.0**）やNaNペイロードによって異なる意味的値を表す可能性があり、コンパイラが異なる金融商品を同じ型として扱ったり、別々であるべき計算をマージしたりする可能性があるため、価格設定ロジックが不正確になる可能性があります。
別の解決策は、トレイト内の関連定数を使用することでした（trait Instrument { const TICK_SIZE: f64; }）。これにより浮動小数点値が許可されますが、ティックサイズを型レベルの識別子として使用する能力が失われます。異なるティックサイズを持つ異なる商品を含む**Vec<Instrument<TICK_SIZE>>**を持つことはできず、dyn Traitオブジェクトのオーバーヘッドに頼らざるを得ず、ホットパスで受け入れられないvtableの間接性を導入します。
選ばれた解決策は、浮動小数点値を固定小数点整数としてエンコードすることでした（例: 0.25 USDをusize 25として、暗黙のスケーリングファクター100を持つ）。このアプローチはconstジェネリックの制約を満たしながら、ゼロコスト抽象化とコンパイル時評価を維持します。その結果、**Bond<25>とBond<50>**はランタイムオーバーヘッドなしで異なる型になり、それぞれ異なるスケーリング規約の文書化が必要ですが、算術エラーを防ぐために慎重に行う必要があります。
なぜRustはcharとboolをconstジェネリックパラメータとして許可しているのに、&strを排除しているのですか？両方は技術的には原始型ですが。
Charとboolは固定サイズの値型であり、単純な構造的等価性を持っています。charは32ビットのUnicodeスカラー値であり、boolは厳密に0または1で、ビットワイズ比較が可能です。&strは、データポインタと長さを含むファットポインタ（またはDSTへの参照）であり、間接性と生存期間パラメータを導入します。コンパイラは、異なるクレート間で二つの文字列リテラルが同じメモリアドレスに存在するか、またはその生存期間が型アイデンティティチェックを許可する**'static要件を満たすかどうかを保証できません。したがって、&strはconstジェネリックパラメータに必要な構造的特性を欠いていますが、charとbool**は自己完結した値です。
浮動小数点型のconstジェネリクスを実装することが、NaN（Not-a-Number）の値に関して型安全性をどのように損なう可能性がありますか？
もしf32が許可されていた場合、MyStructf32::NANやMyStruct<{ 0.0 / 0.0 }>のような式が両方ともNaN値を生成しますが、コンパイラはそれらが同じ型を表していることを保証できません。これは、論理的に同じ型であるはずの二つの異なるモノモルフォシスを作成することを許可するか、逆に、異なるNaNペイロードを含む型を無理にマージするようコンパイラに強いる可能性があり、型アイデンティティの違反が起こる可能性があります。これにより、シングルトンパターンが失敗したり、型ベースの最適化が誤ったコードを生成したりする無効性が生じ、コンパイラが型パラメータが一意の型を特定することを前提にしてしまう可能性があります。
constジェネリックと関連定数の根本的な違いは何ですか？なぜ前者は構造的等価性を必要とし、後者は必要としないのですか？
Constジェネリックパラメータは型アイデンティティの一部であり、Container<10>とContainer<20>は別の型であり、別々のモノモルフォシスを持っています。これにより、値がコンパイル時に比較可能である必要があります。関連定数は型の実装に関連付けられた値ですが、型自体は変更しません。TypeAとTypeBは、それぞれの関連定数の値に関係なく別の型のままです。したがって、関連定数は浮動小数点型や複雑な型を持つことができ、これは実装内での値を提供するだけで、型チェックやモノモルフォシスに影響を与えず、型システムレベルでの構造的等価性の必要性を回避します。