Le trait Any a été introduit tôt dans le développement de Rust pour fournir des capacités de typage dynamique, principalement pour la gestion des erreurs et les scénarios de débogage où les informations de type à la compilation ne sont pas disponibles. Sa conception reflète des concepts similaires dans d'autres langages comme typeid en C++ ou instanceof en Java, mais le modèle de propriété de Rust impose des contraintes uniques. L'exigence 'static est née de la nécessité de garantir que les références effacées par le type ne survivent jamais aux données qu'elles décrivent, empêchant les erreurs d'utilisation après libération dans un langage sans collecte de déchets.
Sans la contrainte 'static, un type effacé comme Any pourrait contenir des références à des données locales à la pile avec une durée de vie limitée. Si l'objet trait Any survit à cette pile d'appels, le downcasting et la déréférenciation accèderaient à de la mémoire désallouée. Comme Any fonctionne via des tables de méthodes (vtables) et l'effacement de type, le compilateur ne peut pas vérifier les durées de vie au moment du downcasting ; la contrainte 'static sert de garantie conservatrice que le type possède toutes ses données ou ne contient que des références statiques, assurant la sécurité mémoire à travers la frontière d'effacement.
La définition du trait Any trait Any: 'static tire parti du système de contraintes de traits de Rust pour imposer cette contrainte au moment de la compilation. Seuls les types ne contenant aucune référence non statique peuvent implémenter Any, ce qui garantit que tout &dyn Any ou Box<dyn Any> reste valide pendant toute la durée du programme. Cela permet un downcasting sûr via downcast_ref() et downcast_mut(), car les données sous-jacentes sont garanties de ne pas être invalidées par les sorties de portée.
Nous construisions un système de plugins pour un moteur de jeu où les scripts pouvaient enregistrer des gestionnaires d'événements retournant des données arbitraires au moteur de base. Le moteur devait stocker ces valeurs de retour dans une file hétérogène pour un traitement ultérieur par différents sous-systèmes, nécessitant un effacement de type pour stocker différents types dans une seule collection. Cependant, certaines liaisons de script tentaient de retourner des références à des variables locales temporaires dans le contexte d'exécution du script, qui deviendraient pendantes une fois le cadre du script terminé.
Solution 1 : Trait personnalisé avec paramètres de durée de vie
Une approche impliquait de créer un trait personnalisé PluginResult avec un type associé pour les paramètres de durée de vie, permettant au moteur de suivre les durées de vie à travers l'objet trait. Cela promettait de la flexibilité en permettant des données empruntées, mais nécessitait des annotations complexes de durée de vie à travers toute la surface de l'API de plugin. La complexité forcerait chaque auteur de plugin à comprendre les mécanismes de durée de vie avancés de Rust, créant une courbe d'apprentissage inacceptable et augmentant le risque de bogues subtils liés aux durées de vie dans le code tiers.
Solution 2 : Transmutation de durée de vie non sécurisée
Une autre solution proposait d'utiliser du code unsafe pour transmuter les durées de vie lors du stockage des données, promettant essentiellement que le moteur supprimerait toutes les références avant la sortie de la portée source. Bien que cela permette l'ergonomie souhaitée de l'API, cela plaçait le poids de la sécurité mémoire entièrement sur les développeurs du moteur. Toute erreur dans le suivi de la provenance des références entraînerait des vulnérabilités exploitables d'utilisation après libération, violant les garanties de sécurité de Rust et rendant le code difficile à auditer.
Nous avons choisi d'exiger que toutes les valeurs de retour de plugin implémentent Any avec la contrainte 'static, forçant les auteurs de scripts à retourner des données possédées ou un état partagé encapsulé dans un Arc. Cette décision a sacrifié certains bénéfices théoriques de performance liés aux références sans copie pour la garantie que la file d'événements du moteur pourrait stocker et traiter les données en toute sécurité de manière asynchrone. Le résultat a été une API de plugin robuste sans code unsafe dans l'interface publique, bien qu'elle ait nécessité d'ajouter des couches de sérialisation pour les types qui dépendaient précédemment de préts momentanés.
Pourquoi le trait Any exige-t-il 'static plutôt que simplement la durée de vie de la référence utilisée pour créer l'objet trait ?
Le trait Any efface les informations de type à la compilation pour produire une vtable, perdant toutes les données de durée de vie dans le processus. Lorsque vous créez &dyn Any, le compilateur ne peut pas encoder la durée de vie originale 'a dans l'objet trait d'une manière que le mécanisme de downcasting peut vérifier ultérieurement. Exiger 'static est la seule façon de garantir que le type sous-jacent ne contient pas de pointeurs pendants sans suivi de durée de vie à l'exécution. Si Any acceptait des durées de vie plus courtes, le pointeur de vtable lui-même devrait porter des métadonnées de durée de vie, ce qui nécessiterait que Rust mette en œuvre des types dépendants ou un contrôle d'emprunt à l'exécution, changeant fondamentalement le modèle d'abstraction à coût nul du langage.
Comment Box<dyn Any> interagit-il avec la contrainte 'static lorsque le type d'origine contient des références non statiques ?
Un type comme struct Wrapper<'a>(&'a str) ne peut pas implémenter Any car il ne satisfait pas la contrainte de trait 'static. Par conséquent, vous ne pouvez pas créer Box<dyn Any> à partir d'une instance de Wrapper<'a>. Les candidats croient souvent à tort que le placement de la valeur dans une boîte prolonge sa durée de vie ; cependant, Box ne possède que l'allocation sur le tas, pas les données référencées par les champs dans cette allocation. Si les données référencées sont locales à la pile, le fait de déplacer la structure externe sur le tas ne prolonge pas la durée de vie de la référence, il est donc correct que le compilateur rejette la conversion en Box<dyn Any>. Cela empêche un scénario où la boîte allouée sur le tas survive au cadre de pile contenant les données référencées.
Pouvez-vous mettre en œuvre en toute sécurité un trait Any personnalisé qui assouplit la contrainte 'static en utilisant du code unsafe et un suivi de durée de vie manuel ?
Bien que techniquement possible en utilisant unsafe pour transmuter des durées de vie et des vtables personnalisées, une telle implémentation serait non sécurisée car le système de traits et le vérificateur d'emprunt de Rust ne peuvent pas vérifier les invariants de durée de vie au site de downcast. Vous devez mettre en œuvre un système de types parallèle suivant les durées de vie à l'exécution, vérifiant à chaque accès que la portée originale existe toujours. Cette approche réimplémente essentiellement un collecteur de déchets ou un système de comptage de références, perdant les garanties à la compilation de Rust. De plus, toute implémentation unsafe interagirait de manière non sécurisée avec les composants de la bibliothèque standard qui attendent les invariants Any, entraînant un comportement indéfini lorsqu'ils sont mélangés avec des objets trait std::any::Any.