Rust maakt polymorfisme mogelijk via trait-objecten (dyn Trait), die vertrouwen op vtables om methode-aanroepen tijdens runtime te dispatchen. Deze vtables worden per implementatie gegenereerd en bevatten strikt functie-pointers die overeenkomen met de methoden van de trait, waardoor een uniforme aanroepconventie over verschillende concrete types wordt vastgesteld.
De opname van geassocieerde constanten (const NAAM: Type;) binnen een trait-definitie voorkomt objectveiligheid omdat constanten compile-tijd constructies zijn die worden opgelost tijdens de monomorfisatie. In tegenstelling tot methoden nemen constanten geen plaatsen in de vtables in, omdat ze geen uniforme runtime-representatie hebben en doorgaans worden ingebed of opgeslagen in alleen-lezen gegevenssecties. Pogingen om een dyn Trait voor zo'n trait te maken, zou vereisen dat het trait-object de constante waarde dynamisch draagt of verwijst, wat in strijd is met het architectonische ontwerp van vtables en type-erasure.
Om dit op te lossen, zou de constante moeten worden omgevormd tot een methode (bijvoorbeeld, fn naam(&self) -> Type) of een geassocieerd type als de waarde een type vertegenwoordigt. Deze wijziging plaatst de waarde-opvraging achter een functie-pointer in de vtable, waardoor de objectveiligheid wordt hersteld met minimale runtime overhead.
Tijdens het ontwerpen van een hardware-abstraheringslaag voor een embedded RTOS, hadden we een uniforme Registry nodig om verschillende sensor-drivers die een Sensor trait implementeren te beheren. Elke driver had een unieke const DEVICE_ID: u16 nodig voor I2C-bus adressering, die we aanvankelijk als een geassocieerde constante binnen de trait hadden gedefinieerd.
Het onmiddellijke obstakel ontstond toen we probeerden heterogene sensoren op te slaan in een Vec<Box<dyn Sensor>>, wat resulteerde in een compilerfout die het schending van de objectveiligheidsregels door de trait aanhaalde. Dit verhinderde de dynamische dispatch die noodzakelijk was voor de registry om sensoren op een generieke manier te polleren.
We evalueerden drie benaderingen. Ten eerste, het omzetten van DEVICE_ID naar een methode fn device_id(&self) -> u16 maakte het mogelijk voor de Vec om correct te functioneren, maar veroorzaakte een vtable-opzoekstraft en verhinderde compile-tijd adresverificatie. Ten tweede, het gebruik van een generieke registry Vec<Box<T>> waar T: Sensor werd afgewezen omdat het homogene opslag vereist, wat de mogelijkheid om temperatuur- en druksensoren te mixen uitsloot. Ten derde, het implementeren van een handmatige type-erasure enum enum DynSensor { Temp(TempSensor), Press(PressSensor) } behield de constanten maar dwong ons om de enum voor elke nieuwe driver te wijzigen, wat het open/gesloten principe schond.
We hebben de eerste oplossing aangenomen, waarbij we de runtime-kosten accepteerden voor de verkregen flexibiliteit. Het resulterende systeem beheerde met succes dertig verschillende sensortypes via een enkele interface, hoewel we de architectonische compromis documenteerden in de richtlijnen van de crate voor toekomstige driver-auteurs.
Waarom kunnen geassocieerde types in trait-objecten worden gebruikt, maar geassocieerde constanten niet, aangezien beide op compile-tijd per implementatie worden opgelost?
Geassocieerde types zijn geïntegreerd in de identiteit van het typesysteem. Bij het construeren van een trait-object zoals Box<dyn Trait<AssocType = u32>> wordt het geassocieerde type onderdeel van de statische typehandtekening die bekend is bij de compiler op de creatieplaats. De vtable blijft geldig omdat het concrete type (en dus het geassocieerde type) vastligt. Daarentegen zijn geassocieerde constanten waarden, geen types. Rust mist syntaxis voor dyn Trait<CONST = 5> en vtables kunnen geen willekeurige gegevenswaarden opslaan — alleen functie-pointers — wat constante waarden ontoegankelijk maakt via het geëraste type.
Zou const generics op de trait geassocieerde constanten met trait-objecten kunnen laten werken door de constante onderdeel van het type te maken?
Het toepassen van const generics (bijvoorbeeld trait Trait<const N: usize>) zou inderdaad de constante onderdeel van het type maken, maar dit sluit heterogene verzamelingen uit. Elke verschillende constante waarde installeert een verschillende trait-type, wat betekent dat Box<dyn Trait<1>> en Box<dyn Trait<2>> incompatibele types zijn die in verschillende Vec-containers worden opgeslagen. Deze benadering offert de polymorfe containercapaciteit op die het gebruik van trait-objecten motiveert, waardoor het ongeschikt is voor registries die gemengde implementaties vereisen.
Hoe beïnvloedt de afwezigheid van geassocieerde constanten in trait-objecten patronen zoals fabriekregistraties of pluginsystemen die afhankelijk zijn van metadata?
Ontwikkelaars proberen vaak te itereren over Vec<Box<dyn Plugin>> om te filteren op een geassocieerde const VERSION: &str, maar ontdekken al snel dat de metadata is geërast. De oplossing houdt in dat metadata naast het trait-object in een wrapper-struct wordt ingesloten (bijvoorbeeld, struct PluginEntry { meta: Metadata, plugin: Box<dyn Plugin> }) of het gebruik van TypeId en Any downcasting om het concrete type te herstellen en toegang te krijgen tot de constanten. Laatstgenoemde vereist 'static grenzen en ontkracht de abstractievoordelen van het trait-object, wat benadrukt dat trait-objecten opzettelijk compile-tijd informatie inruilen voor runtime dynamiek.