De Any trait werd vroeg in de ontwikkeling van Rust geïntroduceerd om dynamische typemogelijkheden te bieden, voornamelijk voor foutafhandeling en debuggingscenario's waarbij type-informatie op compile-tijd niet beschikbaar is. Het ontwerp weerspiegelt vergelijkbare concepten in andere talen zoals C++'s typeid of Java's instanceof, maar het eigendommodel van Rust legt unieke beperkingen op. De 'static vereiste ontstond uit de noodzaak om ervoor te zorgen dat type-erased referenties nooit langer leven dan de gegevens die ze beschrijven, waardoor gebruik-na-vrij fouten in een taal zonder garbage collection worden voorkomen.
Zonder de 'static beperking zou een type dat als Any is verwijderd, verwijzingen naar stack-lokale gegevens met een beperkte levensduur kunnen bevatten. Als het Any trait-object langer leeft dan dat stack-frame, zou downcasting en dereferencering toegang krijgen tot vrijgegeven geheugen. Omdat Any opereert via vtables en type-erasure, kan de compiler levensduren niet verifiëren op het moment van downcasting; de 'static beperking dient als een conservatieve garantie dat het type al zijn gegevens bezit of alleen statische verwijzingen bevat, waarmee geheugenveiligheid over de erasure-grens wordt gewaarborgd.
De definitie van de Any trait trait Any: 'static benut het trait bound-systeem van Rust om deze beperking op compile-tijd af te dwingen. Alleen types zonder non-static verwijzingen kunnen Any implementeren, wat garandeert dat elke &dyn Any of Box<dyn Any> geldig blijft gedurende de hele duur van het programma. Dit maakt veilige downcasting mogelijk via downcast_ref() en downcast_mut(), aangezien de onderliggende gegevens gegarandeerd niet ongeldig worden door het verlaten van scopes.
We waren een plug-in systeem aan het bouwen voor een game-engine waar scripts evenementhandlers konden registreren die willekeurige gegevens naar de kern van de engine terugstuurden. De engine moest deze retourwaarden opslaan in een heterogene wachtrij voor latere verwerking door verschillende subsystemen, wat type-erasure vereiste om verschillende types in een enkele collectie op te slaan. Sommige script bindings probeerden echter verwijzingen terug te geven naar tijdelijke lokale variabelen binnen de uitvoeringscontext van het script, die dangling zouden worden zodra het script-frame was voltooid.
Oplossing 1: Aangepaste trait met levensduurparameters
Een benadering betrof het creëren van een aangepaste trait PluginResult met een geassocieerd type voor levensduurparameters, waardoor de engine levensdurven kon volgen via het trait-object. Dit beloofde flexibiliteit door geleende gegevens toe te staan, maar vereiste complexe levensduurannotaties in de gehele plug-in API oppervlak. De complexiteit zou elke plugin-auteur dwingen om geavanceerde Rust levensduurmechanica te begrijpen, wat een onacceptabel steile leercurve zou creëren en het risico op subtiele levensduurbug in de code van derden zou verhogen.
Oplossing 2: Onveilige levensduur transmutatie
Een andere oplossing stelde voor om unsafe code te gebruiken om levensdurven weg te transmuteren bij het opslaan van de gegevens, en in wezen belovende dat de engine alle verwijzingen zou laten vallen voordat de bron-scope verliet. Hoewel dit de gewenste API-ergonomie mogelijk maakte, legde het de verantwoordelijkheid voor geheugenveiligheid volledig op de ontwikkelaars van de engine. Elke fout in het volgen van de herkomst van verwijzingen zou leiden tot exploiteerbare gebruik-na-vrij kwetsbaarheden, waarmee de veiligheidsgaranties van Rust werden geschonden en de codebase moeilijk te auditen werd.
We besloten dat alle retourwaarden van de plug-in Any met de 'static binding moesten implementeren, waardoor script-auteurs gedwongen werden om eigendomsgegevens of Arc-omhulde gedeelde toestand terug te geven. Deze beslissing offerde enkele theoretische prestatievoordelen van zero-copy verwijzingen op voor de garantie dat de evenementwachtrij van de engine gegevens veilig kon opslaan en asynchroon verwerken. Het resultaat was een robuuste plug-in API zonder unsafe code in de openbare interface, hoewel het vereiste dat er seralizatie lagen werden toegevoegd voor types die eerder vertrouwden op tijdelijke leningen.
Waarom vereist Any 'static in plaats van alleen de levensduur van de verwijzing die is gebruikt om het trait-object te creëren?
De Any trait verwijdert type-informatie op compile-tijd om een vtable te produceren, waarmee alle levensduurgegevens in het proces worden verloren. Wanneer je &dyn Any maakt, kan de compiler de oorspronkelijke levensduur 'a niet in het trait-object coderen op een manier die de downcasting-machinerie later kan verifiëren. Het vereisen van 'static is de enige manier om te waarborgen dat het onderliggende type geen dangling pointers bevat zonder runtime levensduurtracking. Als Any kortere levensduren accepteerde, zou de vtable-pointer zelf levensduurmetadata moeten bevatten, wat zou vereisen dat Rust afhankelijk types of runtime borrow checking implementeert, wat het zero-cost abstractiemodel van de taal fundamenteel zou veranderen.
Hoe interageert Box<dyn Any> met de 'static binding wanneer het oorspronkelijke type non-static verwijzingen bevat?
Een type zoals struct Wrapper<'a>(&'a str) kan geen Any implementeren omdat het niet voldoet aan de 'static trait binding. Als gevolg hiervan kun je geen Box<dyn Any> maken van een Wrapper<'a> instantie. Kandidaten geloven vaak ten onrechte dat het verpakken van de waarde de levensduur verlengt; echter, Box bezit alleen de toewijzing op de heap, niet de gegevens waarnaar velden binnen die toewijzing verwijzen. Als de verwijzende gegevens stack-lokaal zijn, verlengt het verplaatsen van de buitenstruct naar de heap de levensduur van de verwijzing niet, dus wijst de compiler de conversie naar Box<dyn Any> correct af. Dit voorkomt een scenario waarin de op de heap toegewezen doos langer leeft dan het stack-frame dat de verwijzende gegevens bevat.
Kun je veilig een aangepaste Any trait implementeren die de 'static vereiste versoepelt met behulp van unsafe code en handmatige levensduurtracking?
Terwijl het technisch mogelijk is om unsafe te gebruiken om levensdurven te transmuteren en aangepaste vtables, zou een dergelijke implementatie onveilig zijn omdat het trait-systeem en de borrow checker van Rust de levensduurinvarianten op de downcast-locatie niet kunnen verifiëren. Je zou een parallelle typesysteem moeten implementeren dat levensduur bij runtime volgt, op elke toegang controlerend of de oorspronkelijke scope nog steeds bestaat. Deze benadering heeft in wezen een garbage collector of referentietellingssysteem opnieuw geïmplementeerd, waardoor de compile-tijd garanties van Rust verloren gaan. Bovendien zou elke unsafe implementatie onveilig interageren met standaardbibliotheekcomponenten die de Any invarianten verwachten, wat zou leiden tot ongedefinieerd gedrag wanneer gemengd met std::any::Any trait-objecten.