Geschichte: Konstante Generika wurden in Rust 1.51 stabilisiert, um Typen zu ermöglichen, die durch konstante Werte primitiver Ganzzahltypen parametriert sind, was generische Arrays fester Größe wie [T; N] ermöglicht. Während der Entwurfsphase schränkte das Sprachteam explizit konstante generische Parameter auf Typen ein, die strukturelle Gleichheit und deterministische Auswertung zur Kompilierzeit aufweisen. Diese Einschränkung schloss f32, f64 und &str Literale aufgrund ihrer Verletzung der totalen Ordnung oder ihrer Abhängigkeit von Laufzeit-Speicheradressen aus.
Problem: Das Kernproblem mit Fließkommatypen ist das Vorhandensein von NaN (Not-a-Number), das die reflexive Gleichheit verletzt (NaN != NaN), was es dem Compiler unmöglich macht, die Typidentität während der Monomorphisierung zuverlässig zu bestimmen. Bei String-Literalen (&str) liegt das Problem in ihrer dicken Zeiger-Darstellung (Adresse + Länge) und ihrer Abhängigkeit von spezifischen Speicheradressen im Datensegment, die nicht deterministisch über Kompilierungseinheiten oder Crates sind. Das Typsystem erfordert, dass MyStruct<1> und MyStruct<1> immer auf denselben Typ verweisen, was erforderlich macht, dass die Gleichheit des konstanten Parameters zur Kompilierzeit durch bitweise oder strukturelle Vergleiche entscheidbar ist.
Lösung: Der Rust-Compiler setzt diese Einschränkungen durch interne Traits wie StructuralPartialEq (instabil) während der HIR (High-Level Intermediate Representation)-Absenkung und Typüberprüfung durch. Bei der Begegnung eines konstanten generischen Parameters überprüft der Compiler, ob der Typ eine Ganzzahl, bool oder char oder ein benutzerdefinierter Typ ist, der ausdrücklich als unterstützend für strukturelle Gleichheit gekennzeichnet ist. Er lehnt Fließkommatypen ab, weil ihre Gleichheit nicht reflexiv ist, und lehnt Referenzen wie &str ab, da sie Lebenszeiten und Indirektion einführen, die im für konstante Generika erforderlichen 'static-Kontext nicht in Einklang gebracht werden können. Während der Monomorphisierung bewertet der Compiler konstante Ausdrücke und verwendet strukturelle Gleichheit, um identische Instanziierungen zusammenzuführen und die Typensicherheit zu gewährleisten.
// Gültig: usize hat strukturelle Gleichheit struct Matrix<const N: usize> { data: [[f64; N]; N], } // Ungültig: f64 fehlt totale Ordnung (NaN-Probleme) // struct Physics<const G: f64>; // Fehler: Fließkommatypen können nicht in konstanten Generika verwendet werden // Ungültig: &str hat Indirektion und Lebenszeitkomplexität // struct Label<const S: &str>; // Fehler: `&str` ist als Typ eines konstanten generischen Parameters verboten
Sie entwerfen eine Hochfrequenzhandel-Engine, bei der Finanzinstrumente zur Spezifikation von Vertragsbedingungen konstante Parameter zur Kompilierzeit tragen müssen, wie z.B. Tick-Größen (z.B. 0,25 USD) oder Multiplikator-Koeffizienten. Der ursprüngliche Entwurf versuchte, f64 konstante Generika zu verwenden, um diese genauen Dezimalwerte direkt in das Typsystem zu kodieren, in der Hoffnung, die Laufzeitspeicherung dieser Konstanten zu beseitigen und eine Kompilierzeit-Optimierung der Preisberechnungen zu ermöglichen.
Ein in Betracht gezogener Ansatz war, die Einschränkung zu umgehen, indem die f64-Bits in u64 umgewandelt und als konstanten Parameter verwendet wurden, um sie dann innerhalb der Implementierung zurückzuwandeln. Dies erwies sich jedoch als gefährlich, da bitweise identische Fließkommazahlen unterschiedliche semantische Werte aufgrund von signierten Nullwerten (+0.0 vs -0.0) und NaN-Nutzlasten darstellen können, was möglicherweise dazu führt, dass der Compiler unterschiedliche Finanzinstrumente als denselben Typ behandelt oder Berechnungen zusammenführt, die getrennt bleiben sollten, was zu fehlerhafter Preislogik führt.
Eine andere Lösung bestand darin, assoziierte Konstanten innerhalb eines Traits zu verwenden (trait Instrument { const TICK_SIZE: f64; }). Während dies Fließkommawerte ermöglicht, opfert es die Fähigkeit, die Tick-Größe als Typ-Ebenen-Diskriminator zu verwenden; Sie können kein Vec<Instrument<TICK_SIZE>> mit unterschiedlichen Instrumenten und unterschiedlichen Tick-Größen haben, ohne auf die Überkopf von dyn Trait-Objekten zurückzugreifen, was eine VTable-Indirektion einführt, die im heißen Pfad inakzeptabel ist.
Die gewählte Lösung bestand darin, die Fließkommawerte als festes Punkt-Integer (z.B. 0,25 USD als usize 25 mit einem impliziten Skalierungsfaktor von 100 darzustellen) zu kodieren. Dieser Ansatz erfüllt die Einschränkungen der konstanten Generika, während er eine Null-Kosten-Abstraktion und Auswertung zur Kompilierzeit beibehält. Das Ergebnis war ein typsicheres Vertragssystem, bei dem Bond<25> und Bond<50> unterschiedliche Typen ohne Laufzeitkosten sind, obwohl es sorgfältige Dokumentation der Skalierungs-Konvention erforderte, um arithmetische Fehler zu vermeiden.
Warum erlaubt Rust char und bool als konstante generische Parameter, schließt jedoch &str aus, obwohl beide technisch primitive Typen sind?
Char und bool sind Werttypen mit festen Größen und trivialer struktureller Gleichheit; ein char ist ein 32-Bit-Unicode-Skalarenwert und bool ist streng 0 oder 1, was eine bitweise Vergleich erlaubt. &str ist ein dicker Zeiger (oder eine Referenz zu einem DST), die einen Datenzeiger und eine Länge enthält, was Indirektion und Lebenszeitparameter einführt. Der Compiler kann nicht garantieren, dass zwei String-Literale an der gleichen Speicheradresse in verschiedenen Crates liegen oder dass ihre Lebenszeiten die Anforderungen von 'static auf eine Weise erfüllen, die eine Überprüfung der Typidentität zulässt. Folglich fehlen &str die strukturellen Eigenschaften, die für konstante generische Parameter erforderlich sind, während char und bool selbst enthaltene Werte sind.
Wie könnte die Implementierung von konstanten Generika für Fließkommatypen potenziell die Typensicherheit bezüglich NaN (Not-a-Number) Werten gefährden?
Wenn f32 erlaubt wäre, würden Ausdrücke wie MyStructf32::NAN und MyStruct<{ 0.0 / 0.0 }> beide NaN-Werte erzeugen, aber der Compiler könnte nicht garantieren, dass sie denselben Typ repräsentieren, da NaN != NaN. Dies würde die Erstellung von zwei unterschiedlichen Monomorphisierungen ermöglichen, die logisch denselben Typ darstellen sollten, oder umgekehrt den Compiler zwingen, Typen, die unterschiedliche NaN-Lasten enthalten, fälschlicherweise zusammenzuführen. Diese Verletzung der Typidentität könnte zu Unsoundness führen, bei der Singleton-Muster scheitern oder wo typbasierte Optimierungen fehlerhaften Code produzieren, da der Compiler annimmt, dass Typ-Parameter einen einzelnen Typ eindeutig identifizieren.
Was ist der grundlegende Unterschied zwischen konstanten Generika und assoziierten Konstanten, und warum erfordert erstere strukturelle Gleichheit, während letztere das nicht tun?
Konstante generische Parameter sind Teil der Typidentität; Container<10> und Container<20> sind unterschiedliche Typen mit separaten Monomorphisierungen. Dies erfordert, dass die Werte zur Kompilierzeit vergleichbar sind, um globale Eindeutigkeit zu gewährleisten und identische Instanziierungen zusammenzuführen. Assoziierte Konstanten sind Werte, die mit einer Typimplementierung verbunden sind, aber den Typ selbst nicht verändern; TypeA und TypeB bleiben unterschiedliche Typen, unabhängig von ihren assoziierten Konstantenwerten. Daher können assoziierte Konstanten Fließkomma- oder komplexe Typen sein, da sie lediglich Werte innerhalb der Implementierung bereitstellen, ohne die Typprüfung oder Monomorphisierung zu beeinflussen, wodurch die Notwendigkeit struktureller Gleichheit auf der Ebene des Typsystems umgangen wird.