Das Any-Trait wurde früh in der Entwicklung von Rust eingeführt, um dynamische Typing-Möglichkeiten bereitzustellen, hauptsächlich für Fehlerbehandlungs- und Debugging-Szenarien, in denen zur Compile-Zeit keine Typinformationen verfügbar sind. Sein Design spiegelt ähnliche Konzepte in anderen Sprachen wie C++'s typeid oder Java's instanceof wider, aber das Eigentumsmodell von Rust bringt einzigartige Einschränkungen mit sich. Die Anforderung 'static entstand aus der Notwendigkeit sicherzustellen, dass typ-eliminierte Referenzen niemals länger leben als die Daten, die sie beschreiben, um Fehler durch Benutzung nach Freigabe in einer Sprache ohne Garbage Collection zu verhindern.
Ohne die 'static-Bindung könnte ein typ-eliminiert als Any enthaltender Typ Referenzen auf stack-lokale Daten mit begrenzter Lebensdauer enthalten. Wenn das Any-Trait-Objekt länger lebt als dieser Stack-Frame, würden Downcasting und Dereferenzierung auf bereits freigegebenen Speicher zugreifen. Da Any über vtables und Typeliminierung funktioniert, kann der Compiler die Lebensdauern zum Zeitpunkt des Downcastings nicht überprüfen; die 'static-Bindung dient als konservative Garantie dafür, dass der Typ alle seine Daten besitzt oder nur statische Referenzen hält, sodass die Speicher-Integrität über die Eliminierungsgrenze hinweg gewährleistet ist.
Die Definition des Any-Traits trait Any: 'static nutzt das Trait-Bindungs-System von Rust, um diese Einschränkung zur Compile-Zeit durchzusetzen. Nur Typen, die keine nicht-statischen Referenzen enthalten, können Any implementieren, was garantiert, dass jedes &dyn Any oder Box<dyn Any> für die gesamte Programmdauer gültig bleibt. Dies ermöglicht ein sicheres Downcasting über downcast_ref() und downcast_mut(), da die zugrunde liegenden Daten garantiert nicht durch Scopenausgänge ungültig gemacht werden.
Wir entwickelten ein Plug-in-System für eine Spiel-Engine, in dem Skripte Ereignishandler registrieren konnten, die beliebige Daten an die Kern-Engine zurückgaben. Die Engine musste diese Rückgabewerte in einer heterogenen Warteschlange für die spätere Verarbeitung durch verschiedene Teilsysteme speichern, was Typeliminierung erforderte, um unterschiedliche Typen in einer einzigen Sammlung zu speichern. Allerdings versuchten einige Skriptbindungen, Referenzen auf temporäre lokale Variablen im Ausführungskontext des Skripts zurückzugeben, die schwebend wurden, sobald der Skript-Frame abgeschlossen war.
Lösung 1: Benutzerdefiniertes Trait mit Lebenszeitparametern
Ein Ansatz bestand darin, ein benutzerdefiniertes Trait PluginResult mit einem assoziierten Typ für Lebenszeitparameter zu erstellen, das der Engine erlaubte, Lebensdauern über das Trait-Objekt zu verfolgen. Dies versprach Flexibilität, indem es geliehene Daten erlaubte, erforderte jedoch komplexe Lebenszeitannotationen über die gesamte Plugin-API-Oberfläche. Die Komplexität würde jeden Plugin-Autoren zwingen, die fortgeschrittenen Lebenszeitlehren von Rust zu verstehen, was eine inakzeptabel steile Lernkurve verursachte und das Risiko subtiler Lebenszeitfehler im Code Dritter erhöhte.
Lösung 2: Unsichere Lebenszeittransmutation
Eine weitere Lösung schlug vor, unsicheren Code zu verwenden, um Lebenszeiten beim Speichern der Daten zu transmutieren, indem die Engine im Wesentlichen versprach, alle Referenzen zu löschen, bevor der Quellbereich endete. Während dies die gewünschten API-Ergonomien erlaubte, lag die Verantwortung für die Speicherintegrität völlig bei den Entwicklern der Engine. Jeder Fehler bei der Verfolgung der Herkunft von Referenzen würde zu ausnutzbaren Fehlern durch Benutzung nach Freigabe führen, was die Sicherheitsgarantien von Rust verletzen und den Code schwer auditierbar machen würde.
Wir entschieden uns, alle Rückgabewerte von Plugins zur Implementierung von Any mit der 'static-Bindung zu verpflichten, wodurch Skriptautoren gezwungen wurden, besessene Daten oder Arc-umwickelten geteilten Zustand zurückzugeben. Diese Entscheidung opferte einige theoretische Leistungsgewinne von null-Kopie-Referenzen für die Gewissheit, dass die Ereigniswarteschlange der Engine Daten sicher speichern und asynchron verarbeiten konnte. Das Ergebnis war eine robuste Plugin-API ohne unsicheren Code in der öffentlichen Schnittstelle, obwohl es erforderlich war, Serialisierungsschichten für Typen hinzuzufügen, die zuvor auf temporären Entleihungen basierten.
Warum erfordert Any 'static, anstatt nur die Lebenszeit der Referenz, die zum Erstellen des Trait-Objekts verwendet wurde?
Das Any-Trait eliminiert Typinformationen zur Compile-Zeit, um eine vtable zu erstellen, wobei dabei alle Lebenszeitdaten verloren gehen. Wenn Sie &dyn Any erstellen, kann der Compiler die ursprüngliche Lebensdauer 'a nicht in das Trait-Objekt eincodieren, sodass die Downcasting-Maschinerie später verifiziert werden kann. Die Anforderung von 'static ist der einzige Weg, um sicherzustellen, dass der zugrunde liegende Typ keine schwebenden Zeiger enthält, ohne zur Laufzeit Lebenszeiten zu verfolgen. Wenn Any kürzere Lebenszeiten akzeptierte, müsste der vtable-Zeiger selbst Lebenszeitmetadaten mitführen, was verlangen würde, dass Rust abhängige Typen oder Laufzeit-Borrow-Checking implementiert, was das Nullkostenabstraktionsmodell der Sprache grundlegend ändern würde.
Wie interagiert Box<dyn Any> mit der 'static-Bindung, wenn der ursprüngliche Typ nicht-statische Referenzen enthält?
Ein Typ wie struct Wrapper<'a>(&'a str) kann Any nicht implementieren, da er die 'static-Trait-Bindung nicht erfüllt. Folglich können Sie aus einer Wrapper<'a>-Instanz kein Box<dyn Any> erstellen. Kandidaten glauben oft fälschlicherweise, dass das Boxen des Wertes seine Lebenszeit verlängert; jedoch besitzt Box nur die Zuweisung im Heap, nicht die Daten, auf die Felder innerhalb dieser Zuweisung verweisen. Wenn die referenzierten Daten lokal im Stack sind, verlängert das Verschieben der äußeren Struktur in den Heap nicht die Lebensdauer der Referenz, sodass der Compiler die Umwandlung in Box<dyn Any> korrekt ablehnt. Dies verhindert ein Szenario, in dem die im Heap zugewiesene Box länger lebt als der Stack-Frame, der die referenzierten Daten enthält.
Kann man ein benutzerdefiniertes Any-Trait sicher implementieren, das die 'static-Anforderung mithilfe von unsafe-Code und manueller Lebenszeitverfolgung aufhebt?
Obwohl es technisch möglich ist, unsafe zu verwenden, um Lebenszeiten zu transmutieren und benutzerdefinierte vtables zu erstellen, wäre eine solche Implementierung unsound, da das Trait-System und der Borrow-Checker von Rust die Lebenszeit-Invarianten am Downcast-Ort nicht verifizieren können. Es wäre erforderlich, ein paralleles Typsystem zu implementieren, das die Lebenszeiten zur Laufzeit verfolgt und bei jedem Zugriff überprüft, dass der ursprüngliche Bereich noch existiert. Dieser Ansatz implementiert im Wesentlichen einen Garbage Collector oder ein Referenzzählsystem und verliert die Compile-Zeit-Garantien von Rust. Darüber hinaus würde jede unsafe-Implementierung unsound mit Standardbibliothekskomponenten interagieren, die die Any-Invarianten erwarten, was zu undefiniertem Verhalten führen würde, wenn sie mit std::any::Any-Trait-Objekten gemischt wird.