Le compilateur Rust applique la règle de l'orphelin (un élément clé du système de cohérence) pour garantir que chaque paire trait-type a au plus une seule implémentation dans l'ensemble du graphe de dépendances. Cette règle impose qu'un bloc impl est valide uniquement si soit le trait qui est implémenté, soit le type recevant l'implémentation est défini dans la crate actuelle, appelée la crate "locale". En interdisant les implémentations où à la fois le trait et le type sont étrangers (externes), Rust empêche des situations où deux crates indépendantes pourraient introduire des implémentations conflictuelles pour le même objectif, ce qui provoquerait un comportement indéfini ou des ambiguïtés non résolubles dans les projets en aval. L'exception du "type local" permet aux développeurs d'implémenter un trait externe pour un type local (permettant des opérateurs standards sur des structures personnalisées) ou un trait local pour un type externe (permettant des méthodes d'extension), assurant une monomorphisation sans ambiguïté et une abstraction à coût nul sans tables de dispatch à l'exécution.
Notre équipe construisait une bibliothèque serveur GraphQL haute performance qui devait sérialiser les définitions de schéma en JSON en utilisant le framework serde. Nous devions implémenter le trait Serialize de serde pour notre structure locale Schema, ce qui était simple puisque le type était local. Cependant, nous avions également besoin d'un formatage personnalisé pour le type Document de l'externe crate graphql_parser afin de l'intégrer dans notre système de journalisation via le trait standard Display. Cela a créé une tension de conception car à la fois Document et Display étaient étrangers, et nous craignions une rupture future si la crate amont ajoutait sa propre implémentation de Display, créant potentiellement une violation de cohérence pour nos utilisateurs.
La première solution que nous avons envisagée était le modèle Newtype, enveloppant graphql_parser::Document dans une structure tuple struct DocWrapper(graphql_parser::Document) et en implémentant Display sur DocWrapper.
Cette approche respecte parfaitement la règle de l'orphelin car DocWrapper est un type local, et Rust garantit une abstraction à coût nul pour les nouveaux types sans frais d'exécution. Cela nous permet de garder un contrôle total sur l'API et empêche les futurs conflits en amont. Cependant, cela introduit un encombrement significatif pour les conversions et dégrade l'ergonomie, car les utilisateurs doivent envelopper manuellement les instances ou compter sur les implémentations From fournies, encombrant potentiellement l'API publique avec des types de wrapper qui divulguent des détails d'implémentation.
La deuxième solution consistait à créer un trait d'extension, GraphQLDisplay, défini localement dans notre crate, et à l'implémenter directement pour le type étranger Document.
Ceci est légal sous la règle de l'orphelin car le trait lui-même est local, même si le type est étranger, et cela évite la friction ergonomique des types de wrapper tout en permettant une syntaxe de chaînage de méthodes. Le principal inconvénient est que cela ne s'intègre pas avec les macros de formatage standard de Rust comme format! ou println!, qui nécessitent spécifiquement le trait Display ; les utilisateurs devraient importer notre trait personnalisé et appeler une méthode spécifique, créant une expérience disjointe incohérente avec les conventions standard de Rust.
Nous avons finalement choisi le modèle Newtype pour le type Document car la stabilité à long terme et l'intégration dans la bibliothèque standard l'emportaient sur les coûts ergonomiques à court terme. En utilisant DocWrapper, nous avons veillé à ce que notre journalisation d'erreurs puisse utiliser des outils de formatage standard sans macros personnalisées ni importations de traits. Pour le type Schema, nous avons simplement dérivé Serialize puisque à la fois le type et la macro de dérivation étaient locaux. Le résultat était une API cohérente et à l'épreuve du futur où toutes les résolutions de traits étaient sans ambiguïté au moment de la compilation, la compilation est restée rapide en raison de l'absence de frais de résolution d'ambiguïté, et nous avons éliminé le risque de problèmes de dépendance en diamant si graphql_parser introduisait un jour sa propre implémentation de Display.
Comment la règle de l'orphelin s'étend-elle aux types génériques tels que Vec<T>, et pourquoi l'implémentation d'un trait étranger pour Vec<LocalType> est-elle autorisée tandis que Vec<ForeignType> est interdite ?
La règle de l'orphelin s'applique aux types génériques à travers le concept de "couverture de type local", qui exige qu'au moins un paramètre de type au sein de la structure générique soit local à la crate actuelle. Par conséquent, impl ForeignTrait for Vec<LocalType> est valide car LocalType ancre l'implémentation à la crate locale, garantissant qu'aucune autre crate ne peut écrire une implémentation conflictuelle pour ce type concret spécifique. En revanche, impl ForeignTrait for Vec<ForeignType> viole la règle car à la fois le trait et tous les arguments de type sont externes, créant un risque que la crate définissant ForeignType puisse ultérieurement implémenter le même trait pour Vec<ForeignType>, conduisant à des conflits de cohérence. Les candidats manquent souvent que cette couverture s'applique de manière récursive aux génériques imbriqués mais ne s'étend pas au conteneur générique lui-même à moins que ce conteneur ne soit également défini localement.
Pourquoi une implémentation globale (telle que impl<T> Trait for T where T: ToString) dans une crate amont empêche-t-elle les crates en aval d'implémenter ce trait pour des types spécifiques, même locaux ?
Une implémentation globale fournit un comportement par défaut pour tous les types satisfaisant certaines limites de traits, et les règles de cohérence de Rust interdisent toute implémentation concrète qui chevaucherait une implémentation globale existante. Si une crate amont fournit impl<T> Serialize for T where T: ToString, les crates en aval ne peuvent pas implémenter Serialize pour tout type implémentant ToString, même si ce type est local, car le compilateur ne peut garantir que l'implémentation globale et l'implémentation concrète sont mutuellement exclusives. Ceci est distinct de la règle de l'orphelin ; alors que la règle de l'orphelin gouverne qui peut écrire une implémentation, la règle de chevauchement gouverne si deux implémentations valides peuvent coexister dans le même espace de noms. Les candidats confondent fréquemment ces concepts, tentant d'écrire des implémentations concrètes qui sont syntaxiquement valides sous les règles de l'orphelin mais rejetées en raison du chevauchement avec des implémentations globales en amont.
Quel traitement spécial les traits fondamentaux tels que Fn, FnMut et FnOnce reçoivent-ils concernant la règle de l'orphelin, et pourquoi cela permet-il aux closures d'implémenter ces traits sans violer la cohérence ?
La famille de traits Fn est désignée comme "fondamentale", ce qui assouplit la règle de l'orphelin pour autoriser les implémentations de ces traits pour des types étrangers lorsque l'implémentation implique des types locaux dans les paramètres génériques du trait. Cette règle "inversée" traite essentiellement le trait comme local à des fins de cohérence lors de la détermination de l'autorisation d'une implémentation. Par exemple, une closure définie dans votre crate a un type unique et non nommable qui est local à votre crate, et l'implémentation de FnOnce pour cette closure est autorisée même si FnOnce est défini dans la bibliothèque standard et que le type de la closure est opaque. Les candidats manquent souvent de comprendre ce mécanisme car il s'agit d'un détail d'implémentation de la façon dont Rust gère les closures, mais en le comprenant, cela clarifie pourquoi les closures peuvent capturer des environnements locaux et implémenter des traits étrangers sans nécessiter des wrappers de types nouveaux ou déclencher des erreurs de cohérence.