Erreur : "cannot borrow `x` as mutable more than once at a time"

Comprendre la restriction sur les emprunts mutables multiples

L'erreur "cannot borrow `x` as mutable more than once at a time" (souvent associée au code d'erreur `E0499`) est l'une des plus emblématiques du système d'ownership et de borrowing de Rust. Elle découle d'une règle fondamentale conçue pour garantir la sécurité mémoire, en particulier pour prévenir les "data races" (accès concurrents conflictuels à une même donnée) au moment de la compilation. Cette règle stipule qu'à un instant donné, une donnée ne peut avoir qu'une seule référence mutable active. Si vous essayez de créer une deuxième référence mutable vers la même donnée alors que la première est toujours considérée comme active par le compilateur, cette erreur sera déclenchée.

Cette restriction peut sembler contraignante au premier abord, surtout si vous venez de langages plus permissifs. Cependant, elle est la clé qui permet à Rust d'offrir une concurrence sûre sans garbage collector. En garantissant qu'une seule partie du code peut modifier une donnée à un moment donné, Rust élimine toute une catégorie de bugs difficiles à tracer.

Scénario typique déclenchant l'erreur et son explication

Voyons un exemple classique qui provoque cette erreur :

fn main() {
    let mut data = String::from("hello");

    let ref1 = &mut data; // Première référence mutable - OK
    // let ref2 = &mut data; // Tentative de créer une deuxième référence mutable - ERREUR !

    // Si la ligne ci-dessus était décommentée, l'erreur se produirait ici
    // car ref1 est toujours potentiellement utilisable.
    // Par exemple, si on essayait d'utiliser les deux :
    // ref1.push_str(" world");
    // ref2.push_str("!");
    // println!("{} {}", ref1, ref2);

    // Utilisation correcte avec une seule référence active
    ref1.push_str(" world");
    println!("{}", ref1);

    // Maintenant que ref1 n'est plus utilisé (sa portée effective est terminée),
    // nous pouvons créer une nouvelle référence mutable.
    let ref3 = &mut data;
    ref3.push_str(" again");
    println!("{}", ref3);
}

Si vous décommentez la ligne `let ref2 = &mut data;`, le compilateur se plaindra. Pourquoi ? Parce que `ref1` est une référence mutable à `data`. Tant que `ref1` pourrait être utilisée (c'est-à-dire qu'elle est dans son scope et qu'elle n'a pas été "consommée" ou que sa durée de vie n'est pas terminée), Rust interdit la création d'une autre référence mutable (`ref2`) à la même `data`. Si cela était permis, `ref1` et `ref2` pourraient essayer de modifier `data` simultanément ou de manière conflictuelle, menant à un état indéfini.

Le compilateur considère qu'une référence est "active" tant qu'elle est dans son scope et qu'elle n'a pas été surpassée par une nouvelle utilisation de la variable d'origine ou par la fin de sa nécessité. Grâce aux Non-Lexical Lifetimes (NLL), introduites dans les versions plus récentes de Rust, le compilateur est devenu plus intelligent pour déterminer quand une référence n'est réellement plus nécessaire, même si elle est techniquement toujours dans son scope lexical.

Stratégies pour résoudre et éviter cette erreur

Plusieurs approches permettent de résoudre ou d'éviter l'erreur "cannot borrow `x` as mutable more than once at a time" :

1. Limiter la portée de la référence mutable :
La solution la plus simple est souvent de s'assurer que la première référence mutable n'est plus active lorsque vous avez besoin d'en créer une nouvelle. Cela peut être fait en introduisant un nouveau scope avec des accolades `{}` ou simplement en s'assurant que toutes les utilisations de la première référence sont terminées.

fn main() {
    let mut data = vec![1, 2, 3];

    {
        let ref_mut1 = &mut data;
        ref_mut1.push(4);
        // ref_mut1 sort du scope ici, sa durée de vie se termine.
    }

    // Maintenant, il est sûr de créer une autre référence mutable.
    let ref_mut2 = &mut data;
    ref_mut2.push(5);
    println!("{:?}", ref_mut2);
}

2. Réorganiser le code ou utiliser des fonctions :
Parfois, une réorganisation logique du code peut éviter le besoin de multiples références mutables simultanées. Si une opération nécessite une modification, elle peut être encapsulée dans une fonction qui prend une référence mutable, effectue son travail, puis la "rend".

fn ajouter_element(vecteur: &mut Vec, element: i32) {
    vecteur.push(element);
}

fn main() {
    let mut mon_vec = vec![10, 20];
    ajouter_element(&mut mon_vec, 30); // Emprunt mutable, utilisé, puis rendu
    ajouter_element(&mut mon_vec, 40); // Nouvel emprunt mutable possible
    println!("{:?}", mon_vec);
}

3. Comprendre les Non-Lexical Lifetimes (NLL) :
Avec NLL, le compilateur est plus précis. Une référence n'est considérée active que jusqu'à sa dernière utilisation. Cela signifie que même au sein du même scope lexical, vous pouvez souvent ré-emprunter de manière mutable si l'emprunt précédent n'est plus utilisé.

fn main() {
    let mut data = String::from("initial");

    let r1 = &mut data;
    r1.push_str("変更1");
    println!("Après r1: {}", r1); // Dernière utilisation de r1

    // Puisque r1 n'est plus utilisé après le println! ci-dessus,
    // il est permis de créer r2.
    let r2 = &mut data;
    r2.push_str("変更2");
    println!("Après r2: {}", r2); // Dernière utilisation de r2
}

Dans cet exemple, même si `r1` et `r2` sont dans le même scope, le compilateur comprend que `r1` n'est plus nécessaire après son `println!`, libérant ainsi la voie pour `r2`.

4. Cas des itérateurs et des méthodes de struct :
Cette erreur peut aussi survenir de manière plus subtile, par exemple lorsque vous essayez de modifier une collection pendant que vous itérez dessus, ou lorsque vous appelez une méthode qui prend `&mut self` sur un objet alors qu'une autre référence mutable à une partie de cet objet existe déjà. La solution implique souvent de collecter les modifications nécessaires puis de les appliquer après l'itération, ou de restructurer l'accès aux données.

En comprenant que cette règle vise à prévenir les bugs, on apprend à structurer son code d'une manière qui respecte naturellement cette contrainte. Cela conduit souvent à des conceptions plus claires et plus robustes.