Historique : Les génériques constants ont été stabilisés dans Rust 1.51 pour permettre aux types d'être paramétrés par des valeurs constantes de types entiers primitifs, permettant ainsi des tableaux de taille fixe génériques comme [T; N]. Pendant la phase de conception, l'équipe de langue a explicitement restreint les paramètres génériques constants aux types qui présentent une égalité structurelle et une évaluation déterministe à la compilation. Cette restriction exclut f32, f64, et les littéraux &str en raison de leur violation de l'ordre total ou de leur dépendance à des adresses mémoire à l'exécution.
Problème : Le problème central avec les types à virgule flottante est la présence de NaN (Not-a-Number), qui viole l'égalité réflexive (NaN != NaN), empêchant le compilateur de déterminer de manière fiable l'identité du type lors de la monomorphisation. Pour les littéraux de chaîne (&str), le problème réside dans leur représentation de pointeur lourd (adresse + longueur) et leur dépendance à des adresses mémoire spécifiques dans le segment de données, qui ne sont pas déterministes à travers les unités de compilation ou les crates. Le système de types exige que MyStruct<1> et MyStruct<1> fassent toujours référence au même type, nécessitant que l'égalité du paramètre constant soit décidée par comparaison bit à bit ou structurelle à la compilation.
Solution : Le compilateur Rust impose ces contraintes par le biais de traits internes comme StructuralPartialEq (instable) lors de la réduction HIR (High-Level Intermediate Representation) et de la vérification des types. Lorsqu'il rencontre un paramètre générique constant, le compilateur vérifie que le type est un entier, un bool ou un char, ou un type défini par l'utilisateur explicitement marqué comme supportant l'égalité structurelle. Il rejette les types à virgule flottante parce que leur égalité n'est pas réflexive et rejette les références comme &str parce qu'elles introduisent des durées de vie et de l'indirection qui ne peuvent pas être conciliées dans le contexte 'static requis pour les génériques constants. Lors de la monomorphisation, le compilateur évalue les expressions constantes et utilise l'égalité structurelle pour fusionner les instanciations identiques, garantissant ainsi la sécurité des types.
// Valide : usize a une égalité structurelle struct Matrix<const N: usize> { data: [[f64; N]; N], } // Invalide : f64 manque d'un ordre total (problèmes de NaN) // struct Physics<const G: f64>; // Erreur : les types à virgule flottante ne peuvent pas être utilisés dans des génériques constants // Invalide : &str a une complexité d'indirection et de durée de vie // struct Label<const S: &str>; // Erreur : `&str` est interdit en tant que type d'un paramètre générique constant
Vous concevez un moteur de trading à haute fréquence où les instruments financiers doivent porter des paramètres constants à la compilation pour les spécifications des contrats, tels que les tailles de ticks (par exemple, 0.25 USD) ou les coefficients multiplicateurs. La conception initiale tentait d'utiliser des génériques constants f64 pour encoder ces valeurs décimales précises directement dans le système de types, espérant éliminer le stockage à l'exécution de ces constantes et permettre l'optimisation des calculs de prix à la compilation.
Une approche envisagée consistait à contourner la restriction en transmutant les bits f64 en u64 et en utilisant cela comme le paramètre constant, puis à transmuter à nouveau dans l'implémentation. Cependant, cela s'est avéré dangereux car des flottants identiques au niveau des bits peuvent représenter différentes valeurs sémantiques en raison de zéro signé (+0.0 vs -0.0) et des charges NaN, pouvant potentiellement amener le compilateur à traiter des instruments financiers distincts comme le même type ou à fusionner des calculs qui devraient rester séparés, aboutissant à une logique de prix incorrecte.
Une autre solution impliquait l'utilisation de constantes associées au sein d'un trait (trait Instrument { const TICK_SIZE: f64; }). Bien que cela permette des valeurs à virgule flottante, cela sacrifie la capacité d'utiliser la taille de tick comme un discriminateur de niveau type ; vous ne pouvez pas avoir Vec<Instrument<TICK_SIZE>> contenant différents instruments avec différentes tailles de ticks sans recourir aux objets dyn Trait, ce qui introduit une indirection vtable inacceptable dans le chemin critique.
La solution choisie a été d'encoder les valeurs à virgule flottante en tant qu'entiers fixes (par exemple, représentant 0.25 USD comme le usize 25 avec un facteur d'échelle implicite de 100). Cette approche satisfait les contraintes des génériques constants tout en maintenant une abstraction à coût nul et une évaluation à la compilation. Le résultat était un système de contrat sûr sur le plan des types où Bond<25> et Bond<50> sont des types distincts sans surcharge à l'exécution, bien qu'il ait nécessité une documentation soigneuse de la convention d'échelle pour éviter des erreurs arithmétiques.
Pourquoi Rust permet-il char et bool en tant que paramètres génériques constants mais exclut-il &str, étant donné que les deux sont techniquement des types primitifs ?
Char et bool sont des types de valeur avec des tailles fixes et une égalité structurelle triviale ; un char est une valeur scalaire Unicode de 32 bits et bool est strictement 0 ou 1, permettant une comparaison bit à bit. &str est un pointeur lourd (ou référence à un DST) contenant un pointeur de données et une longueur, introduisant de l'indirection et des paramètres de durée de vie. Le compilateur ne peut pas garantir que deux littéraux de chaîne résident à la même adresse mémoire à travers différentes crates ou que leurs durées de vie satisfont les exigences 'static d'une manière qui permette une vérification de l'identité de type. Par conséquent, &str manque des propriétés structurelles requises pour les paramètres génériques constants, tandis que char et bool sont des valeurs autonomes.
Comment l'implémentation de génériques constants pour les types à virgule flottante pourrait-elle potentiellement rompre la sécurité des types concernant les valeurs NaN (Not-a-Number) ?
Si f32 était permis, des expressions comme MyStructf32::NAN et MyStruct<{ 0.0 / 0.0 }> produiraient toutes deux des valeurs NaN, mais le compilateur ne pourrait pas garantir qu'elles représentent le même type car NaN != NaN. Cela permettrait la création de deux monomorphisations distinctes de ce qui devrait logiquement être le même type, ou inversement, forcer le compilateur à fusionner incorrectement des types contenant différentes charges NaN. Cette violation de l'identité de type pourrait conduire à une insécurité où les motifs singleton échouent ou où les optimisations basées sur le type produisent un code incorrect, car le compilateur suppose que les paramètres de type identifient de manière unique un seul type.
Quelle est la distinction fondamentale entre les génériques constants et les constantes associées, et pourquoi le premier nécessite-t-il une égalité structurelle tandis que le second ne le fait pas ?
Les paramètres génériques constants font partie de l'identité de type ; Container<10> et Container<20> sont des types distincts avec des monomorphisations séparées. Cela nécessite que les valeurs soient comparables à la compilation pour garantir l'unicité globale et pour fusionner les instanciations identiques. Les constantes associées sont des valeurs associées à une implémentation de type mais ne modifient pas le type lui-même ; TypeA et TypeB restent des types distincts indépendamment de leurs valeurs constantes associées. Par conséquent, les constantes associées peuvent être de types à virgule flottante ou complexes parce qu'elles fournissent simplement des valeurs au sein de l'implémentation sans affecter la vérification des types ou la monomorphisation, contournant ainsi le besoin d'égalité structurelle au niveau du système de types.