Rust permet le polymorphisme par le biais des objets de trait (dyn Trait), qui s'appuient sur des vtables pour dispatcher les appels de méthode à l'exécution. Ces vtables sont générées par implémentation et contiennent strictement des pointeurs de fonction correspondant aux méthodes du trait, établissant une convention d'appel uniforme à travers différents types concrets.
L'inclusion de constantes associées (const NAME: Type;) dans la définition d'un trait empêche la sécurité d'objet car les constantes sont des constructions à temps de compilation résolues lors de la mono-morphisation. Contrairement aux méthodes, les constantes n'occupent pas d'emplacements dans les vtables, car elles n'ont pas de représentation d'exécution uniforme et sont généralement inlinées ou stockées dans des sections de données en lecture seule. Tenter de créer un dyn Trait pour un tel trait nécessiterait que l'objet de trait transporte ou référence la valeur constante dynamiquement, ce qui contredit la conception architecturale des vtables et de l'effacement de type.
Pour résoudre cela, la constante doit être transformée en une méthode (par exemple, fn name(&self) -> Type) ou en un type associé si la valeur représente un type. Cette modification place la récupération de valeur derrière un pointeur de fonction dans la vtable, restaurant ainsi la sécurité d'objet tout en introduisant un coût d'exécution minimal.
Lors de l'architecture d'une couche d'abstraction matérielle pour un RTOS embarqué, nous avions besoin d'un Registre unifié pour gérer des pilotes de capteurs disparates implémentant un trait Capteur. Chaque pilote nécessitait un const DEVICE_ID: u16 unique pour l'adressage du bus I2C, que nous avons initialement défini comme une constante associée dans le trait.
L'obstacle immédiat est survenu lors de la tentative de stocker des capteurs hétérogènes dans un Vec<Box<dyn Sensor>>, entraînant une erreur du compilateur citant la violation des règles de sécurité d'objet du trait. Cela a empêché le dispatch dynamique nécessaire pour que le registre interroge les capteurs de manière générique.
Nous avons évalué trois approches. Premièrement, convertir DEVICE_ID en une méthode fn device_id(&self) -> u16 a permis au Vec de fonctionner correctement mais a entraîné un coût de recherche dans la vtable et empêché la vérification d'adresse à temps de compilation. Deuxièmement, l'utilisation d'un registre générique Vec<Box<T>> où T: Sensor a été rejetée parce qu'elle nécessitait un stockage homogène, éliminant la possibilité de mélanger des capteurs de température et de pression. Troisièmement, implémenter un énumérateur d'effacement de type manuel enum DynSensor { Temp(TempSensor), Press(PressSensor) } préservait les constantes mais nous a forcés à modifier l'énumérateur pour chaque nouveau pilote, violant le principe d'ouverture/fermeture.
Nous avons adopté la première solution, acceptant le coût d'exécution pour la flexibilité gagnée. Le système résultant gérait avec succès trente types de capteurs distincts via une seule interface, bien que nous aillons documenté le compromis architectural dans les directives du crate pour de futurs auteurs de pilotes.
Pourquoi les types associés peuvent-ils être utilisés dans des objets de trait mais pas les constantes associées, étant donné que les deux sont résolus à la compilation par implémentation ?
Les types associés sont intégrés dans l'identité du système de types. Lors de la construction d'un objet de trait comme Box<dyn Trait<AssocType = u32>>, le type associé devient une partie de la signature de type statique connue du compilateur au site de création. La vtable reste valide car le type concret (et donc le type associé) est fixe. En revanche, les constantes associées sont des valeurs, pas des types. Rust n'a pas de syntaxe pour dyn Trait<CONST = 5> et les vtables ne peuvent pas stocker des valeurs de données arbitraires—seulement des pointeurs de fonction—rendant les constantes inaccessibles à travers le type effacé.
Les génériques const sur le trait permettraient-ils aux constantes associées de fonctionner avec des objets de trait en rendant la constante partie du type ?
Appliquer des génériques const (par exemple, trait Trait<const N: usize>) ferait effectivement de la constante une partie du type, mais cela exclut les collections hétérogènes. Chaque valeur constante distincte instancie un type de trait distinct, ce qui signifie que Box<dyn Trait<1>> et Box<dyn Trait<2>> sont des types incompatibles stockés dans différents conteneurs Vec. Cette approche sacrifie la capacité du conteneur polymorphe qui motive l'utilisation d'objets de trait, rendant cela inadapté aux registres nécessitant des implémentations mixtes.
Comment l'absence de constantes associées dans les objets de trait impacte-t-elle des modèles comme les registres d'usine ou les systèmes de plugins qui reposent sur des métadonnées ?
Les développeurs tentent souvent de parcourir Vec<Box<dyn Plugin>> pour filtrer par un const VERSION: &str associé, seulement pour découvrir que les métadonnées sont effacées. La solution implique soit d'incorporer des métadonnées aux côtés de l'objet de trait dans une structure d'encapsulation (par exemple, struct PluginEntry { meta: Metadata, plugin: Box<dyn Plugin> }), soit d'utiliser TypeId et Any pour rétro-décomposer afin de récupérer le type concret et accéder à ses constantes. Ce dernier nécessite des limites 'static et annule les avantages d'abstraction de l'objet de trait, soulignant que les objets de trait échangent délibérément des informations à temps de compilation pour un dynamisme à temps d'exécution.