Réponse

En Rust, il existe deux types principaux de références :

Références immuables (&T) : offrent un accès en lecture seule.
Références mutables (&mut T) : permettent de modifier la valeur à laquelle elles pointent.

Règles :

On peut avoir soit un nombre quelconque de références immuables, soit une seule référence mutable à la fois ; il est interdit de les mélanger dans le même espace de visibilité.
Les références ont leur propre durée de vie (lifetime), qui est analysée au moment de la compilation.

Exemples de syntaxe :

fn read(val: &i32) {
   println!("{}", val);
}

fn write(val: &mut i32) {
   *val += 1;
}

let mut x = 5;
read(&x);
write(&mut x);

Question piège

Question : Peut-on créer deux références mutables sur une même variable dans différents espaces de visibilité d'une même fonction ?

Réponse : Non, même si les références sont créées dans différents blocs, l'espace de visibilité pour l'analyse des emprunts couvre toute la fonction ou la variable, si le compilateur ne peut pas prouver de manière précise que les références ne se chevauchent pas. Cela se traduit souvent par des erreurs de compilation :

let mut x = 10;
let r1 = &mut x;
{
    let r2 = &mut x; // erreur!
}

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

Histoire

Dans le développement d'un parser, un développeur a tenté de conserver à la fois une référence mutable et une référence immuable sur un même buffer pour optimiser la lecture et l'écriture. En conséquence, le code ne compilait pas, et après avoir "contourné" la règle via du code non sécurisé, des bugs de fuite de données sont apparus.

Histoire

Au début d'un projet de traitement de données, l'un des participants n'a pas exécuté "reanalyze borrow checker" pour un code complexe avec des espaces imbriqués. En conséquence, à cause de références qui se chevauchaient, l'erreur classique "cannot borrow as mutable because it's also borrowed as immutable" est apparue sans indication explicite de l'endroit du problème dans le code source.

Histoire

Dans un code multithread, des références ordinaires ont été utilisées pour accéder à des données partagées. Lors de la tentative de modifier les données dans des threads parallèles, des erreurs de compilation inattendues et des courses de données se sont produites lors de la traversée du borrow checker via du code non sécurisé.