Les pièges classiques de l'ownership et du borrowing

Naviguer dans les méandres de l'ownership et du borrowing en Rust

Les concepts d'ownership (possession) et de borrowing (emprunt) sont au coeur du système de gestion de la mémoire de Rust, lui conférant sa réputation de sécurité sans nécessiter de garbage collector. Si ces mécanismes sont puissants, ils représentent souvent une courbe d'apprentissage initiale pour les développeurs venant d'autres langages. Comprendre les erreurs classiques qui en découlent est essentiel pour écrire du code Rust idiomatique et fonctionnel. Ce chapitre se penche sur les pièges les plus fréquents et vous donne les clés pour les anticiper et les résoudre.

Nous aborderons trois types d'erreurs ou de concepts qui reviennent fréquemment. D'abord, la fameuse erreur "cannot borrow `x` as mutable more than once at a time", qui illustre la règle stricte de Rust concernant les références mutables. Ensuite, nous analyserons l'erreur "use of moved value", conséquence directe du système de possession et du transfert de celle-ci. Enfin, nous introduirons de manière conceptuelle les durées de vie (lifetimes), en expliquant leur raison d'être sans pour autant plonger immédiatement dans leur syntaxe parfois intimidante. L'objectif est de démystifier ces aspects pour vous permettre de coder avec plus de confiance.

L'exclusivité de la mutation : "cannot borrow `x` as mutable more than once at a time"

L'une des règles fondamentales du borrowing en Rust stipule que vous ne pouvez avoir qu'une seule référence mutable (`&mut T`) à une donnée particulière dans un scope donné. Si vous tentez d'en créer une seconde alors que la première est toujours active, le compilateur interviendra avec le message d'erreur : "cannot borrow `x` as mutable more than once at a time". Cette restriction est cruciale pour prévenir les "data races" (accès concurrents conflictuels à la mémoire) au moment de la compilation, une source majeure de bugs dans d'autres langages.

Considérez l'exemple suivant :

fn main() {
    let mut s = String::from("bonjour");

    let r1 = &mut s; // Première référence mutable, OK
    // let r2 = &mut s; // Erreur ! Deuxième référence mutable active

    // println!("{}, {}", r1, r2); // Si r2 était décommenté, cette ligne causerait l'erreur
    println!("{}", r1); // Avec r2 commenté, ceci fonctionne
    // Après ce point, r1 n'est plus utilisé, on pourrait créer une nouvelle référence mutable :
    let r3 = &mut s;
    r3.push_str(" le monde");
    println!("{}", r3);
}

Dans ce code, si la ligne `let r2 = &mut s;` était décommentée, le compilateur signalerait une erreur. La première référence mutable `r1` est toujours considérée comme active car elle pourrait être utilisée plus tard (par exemple dans le `println!`). Pour résoudre ce type d'erreur, il faut s'assurer que les scopes des références mutables ne se chevauchent pas ou que la première référence mutable n'est plus utilisée lorsque la seconde est créée. Parfois, il suffit de limiter la portée de la première référence en utilisant des blocs `{}` ou en s'assurant qu'elle n'est plus nécessaire.

Il est important de noter que vous pouvez avoir plusieurs références immuables (`&T`) ou une seule référence mutable, mais pas les deux en même temps si la référence mutable existe déjà ou si une référence immuable est toujours active et que vous tentez de créer une référence mutable. Cette règle, "aliasing XOR mutability", est une pierre angulaire de la sécurité en Rust.

La valeur éphémère : "use of moved value"

En Rust, lorsqu'une valeur dont le type n'implémente pas le trait `Copy` est assignée à une autre variable ou passée à une fonction, sa possession est transférée (on parle de "move"). La variable d'origine n'est alors plus considérée comme propriétaire de la donnée et ne peut plus être utilisée. Tenter de l'utiliser après ce transfert conduit à l'erreur "use of moved value". Cela s'applique principalement aux types qui gèrent des ressources sur le tas, comme `String`, `Vec<T>`, ou les `Box<T>`.

Voici une illustration typique :

fn main() {
    let s1 = String::from("contenu");
    let s2 = s1; // La possession de la donnée de s1 est transférée à s2.
                 // s1 n'est plus valide ici.

    // println!("s1 contient : {}", s1); // Erreur : use of moved value: `s1`
    println!("s2 contient : {}", s2); // OK, s2 possède la donnée.
}

Après `let s2 = s1;`, `s1` est invalidée car `String` ne possède pas le trait `Copy`. Tenter d'utiliser `s1` dans le `println!` provoquerait une erreur de compilation. Ce comportement prévient les problèmes de double libération de mémoire (double free) qui peuvent survenir lorsque deux variables pensent posséder et donc devoir libérer la même ressource mémoire.

Pour contourner ce problème, plusieurs stratégies existent :

1. Si vous avez besoin d'une copie indépendante de la donnée, vous pouvez utiliser la méthode `.clone()`, à condition que le type l'implémente : `let s2 = s1.clone();`. Dans ce cas, `s1` reste valide.
2. Si vous souhaitez seulement lire la donnée ou la modifier temporairement sans en prendre possession, vous pouvez utiliser des références (emprunts) : `fn une_fonction(val: &String) { ... }`.
3. La fonction qui reçoit la valeur peut la retourner, transférant ainsi à nouveau la possession.

Introduction aux durées de vie (lifetimes) : pourquoi elles existent

Les durées de vie (lifetimes) sont un concept central, bien que parfois perçu comme complexe, qui permet au compilateur Rust de s'assurer que toutes les références utilisées dans votre programme sont toujours valides. Elles constituent le mécanisme par lequel Rust prévient les références pendantes (dangling references) sans avoir recours à un garbage collector. Une référence pendante est une référence qui pointe vers une donnée qui n'existe plus (parce qu'elle a été libérée ou est sortie de sa portée). Ce type de bug est une source notoire de plantages et de failles de sécurité dans d'autres langages systèmes.

L'idée fondamentale des durées de vie est de s'assurer qu'une donnée référencée (la "référée") vit au moins aussi longtemps que toutes les références qui pointent vers elle. Le compilateur Rust, grâce à son "borrow checker", analyse les durées de vie pour vérifier cette condition. Dans de nombreux cas simples, le compilateur peut inférer les durées de vie automatiquement (c'est ce qu'on appelle "l'élision des durées de vie"), et vous n'avez pas besoin de les annoter explicitement dans votre code.

Cependant, dans certaines situations plus complexes, notamment lorsque des références sont stockées dans des structures (`struct`) ou retournées par des fonctions, le compilateur peut avoir besoin d'aide pour déterminer les relations entre les durées de vie. C'est là qu'interviennent les annotations de durée de vie explicites (par exemple, `&'a T`). Pour l'instant, l'objectif n'est pas de maîtriser cette syntaxe, mais de comprendre pourquoi ce concept existe. Les durées de vie sont la réponse de Rust au problème de la validité des références. Elles formalisent la notion de "cette référence est valide tant que cette donnée existe".

Imaginez que vous retournez une référence à une variable locale d'une fonction. Une fois la fonction terminée, sa variable locale est détruite. Si la référence persistait, elle pointerait vers une mémoire invalide. Le système de durées de vie interdit ce genre de scénario au moment de la compilation. En comprenant que les durées de vie servent à garantir que les emprunts ne survivent pas aux données qu'ils référencent, vous saisirez mieux pourquoi certaines constructions de code sont acceptées par le compilateur et d'autres, rejetées avec des messages d'erreur liés aux durées de vie.