Traits Rust contre interfaces Go : impl explicite, satisfaction implicite

Ce que c'est

Go : la spécification indique qu'un type implémente une interface lorsqu'il appartient à l'ensemble de types de l'interface, ce qui, pour les interfaces ne contenant que des méthodes, signifie qu'il possède ces méthodes ; aucune déclaration ne relie les deux. Rust : un trait déclare des méthodes requises et, optionnellement, des méthodes par défaut, et un type ne l'acquiert que par impl Trait for Type. Le livre Rust explique la règle de l'orphelin, qui fait partie de la cohérence : une implémentation n'est autorisée que si le trait ou le type est local à la crate courante, ce qui garantit que deux crates ne peuvent pas fournir des implémentations en conflit. Les traits peuvent porter des types et des constantes associés, servir de contraintes sur des génériques (fn f<T: Display>(x: T) ou impl Display en position d'argument ou de retour), et être transformés en objets trait (Box<dyn Display>). Le livre décrit les génériques comme monomorphisés à la compilation (une copie du code par type concret, répartition statique) et les objets trait comme une répartition dynamique résolue à l'exécution. Les valeurs d'interface Go font toujours l'objet d'une répartition dynamique ; les génériques Go (depuis la 1.18) utilisent des interfaces comme contraintes.

Pourquoi c'est important

Les deux répondent à la première question que se posent les programmeurs venus d'un langage dynamique : comment écrire du code pour plusieurs types sans héritage. L'impl explicite de Rust signifie qu'un type ne peut pas satisfaire un trait par accident, et la règle de l'orphelin signifie qu'un trait étranger ne peut pas être implémenté directement pour un type étranger ; le motif newtype (une structure enveloppe à un seul champ) est le moyen habituel de contourner cela. L'implicite de Go signifie qu'une interface peut être définie après coup, du côté du consommateur, pour des types que ce dernier ne possède pas, ce qui est la façon dont les tests injectent des simulacres (fakes) pour des clients tiers.

Comment l'appliquer

• En Go, définir de petites interfaces au point d'usage ; en Rust, définir les traits là où le comportement est spécifié, et les implémenter pour des types étrangers via un newtype local lorsque nécessaire.
• En Rust, préférer les génériques avec contraintes pour les chemins critiques et les collections homogènes, et dyn Trait lorsqu'une collection doit contenir des types différents ou lorsque le temps de compilation et la taille du binaire importent plus que le coût de répartition.
• Utiliser des méthodes par défaut et des implémentations générales (impl<T: Display> Describe for T) pour donner un comportement à de nombreux types à la fois ; Go n'a pas d'équivalent et s'appuie sur l'inclusion (embedding) et des fonctions utilitaires.
• Dériver les traits standards (Debug, Clone, PartialEq) avec #[derive] ; en Go, implémenter String() et Error() à la main.

Pièges

Rust : un trait doit être importé (use) pour que ses méthodes soient appelables, et le livre note que Rust a des règles sur où la répartition dynamique peut être utilisée, appelées compatibilité dyn, de sorte que tout trait ne peut pas devenir un dyn Trait. Go : un type dont les méthodes ont un récepteur pointeur ne satisfait l'interface qu'en tant que pointeur, et une valeur d'interface contenant un pointeur nil n'est pas nil.