Propriété et emprunt en Rust : vue d'ensemble

Ce que c'est

Le livre Rust énonce trois règles : chaque valeur a un propriétaire, il ne peut y avoir qu'un seul propriétaire à la fois, et lorsque le propriétaire sort de portée, la valeur est détruite (drop). Affecter ou passer une valeur possédant des données sur le tas, comme un String, la déplace ; utiliser ensuite l'ancienne liaison est une erreur de compilation, et non une surprise à l'exécution. Les types qui vivent entièrement sur la pile (entiers, bool, char, et leurs tuples) implémentent Copy et sont dupliqués à la place, tandis que .clone() effectue une copie profonde explicite. Une référence (&T ou &mut T) emprunte une valeur sans en prendre la propriété ; le livre donne deux règles pour les références : à un instant donné, soit une seule référence mutable, soit un nombre quelconque de références immuables, et les références doivent toujours être valides. Le vérificateur d'emprunts du compilateur rejette une référence qui survivrait à sa valeur (une référence pendante) ainsi qu'une mutation pendant qu'une référence partagée est active. Le livre oppose cela aux langages dotés d'un ramasse-miettes, où le collecteur suit la mémoire qui n'est plus utilisée.

Pourquoi c'est important

En Python ou en JavaScript, chaque objet est partagé par référence et libéré par le collecteur ; l'aliasing combiné à la mutation est normal, et parfois un bug. Les règles de Rust transforment cette classe de bugs, ainsi que l'invalidation d'itérateurs et les accès concurrents aux données, en erreurs de compilation. Le coût est que des motifs auparavant gratuits (deux structures détenant le même objet, une méthode renvoyant une référence vers un temporaire) exigent désormais un choix délibéré.

Comment l'appliquer

• Privilégier par défaut le passage de références : &T pour la lecture et &mut T pour les modifications en place ; ne passer la propriété que lorsque l'appelé doit conserver la valeur.
• Renvoyer des valeurs possédées depuis les constructeurs et les analyseurs ; ne renvoyer une référence que lorsque le résultat emprunte à un argument, et laisser le compilateur demander une annotation de durée de vie lorsqu'il ne peut pas déduire le lien.
• Utiliser Rc<T> (mono-thread) ou Arc<T> (partagé entre threads) lorsque plusieurs propriétaires sont réellement nécessaires, et RefCell ou Mutex lorsque des données partagées doivent aussi être modifiées.
• Lorsque le vérificateur proteste, restructurer d'abord (raccourcir l'emprunt, cloner une petite valeur, scinder une structure en parties empruntées indépendamment) avant de recourir à unsafe.

Pièges

Conserver un & vers un Vec tout en y insérant des éléments. Itérer une collection par valeur (for x in v) la déplace ; itérer &v pour la conserver. Stocker des références dans une structure rend celle-ci générique sur une durée de vie. Appeler clone() sur de grandes données pour faire taire le vérificateur masque le problème de conception au lieu de le résoudre.