Antwort

In Rust gibt es zwei grundlegende Arten von Referenzen:

Unveränderliche Referenzen (&T): bieten nur Lesezugriff.
Veränderliche Referenzen (&mut T): erlauben das Ändern des Wertes, auf den verwiesen wird.

Regeln:

Es kann entweder eine beliebige Anzahl von unveränderlichen Referenzen oder nur eine Veränderliche gleichzeitig existieren; sie dürfen nicht im selben Gültigkeitsbereich vermischt werden.
Referenzen haben eine Lebensdauer, die zur Kompilierzeit analysiert wird.

Syntaxbeispiele:

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

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

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

Fangfrage

Frage: Kann man zwei veränderliche Referenzen auf eine Variable in verschiedenen Sichtbarkeiten derselben Funktion erstellen?

Antwort: Nein, auch wenn die Referenzen in verschiedenen Blöcken erstellt werden, umfasst der Sichtbarkeitsbereich für die Leihüberprüfung die gesamte Funktion oder Variable, es sei denn, der Compiler kann eindeutig nachweisen, dass die Referenzen sich nicht überlappen. Dies führt oft zu Kompilierungsfehlern:

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

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas

Geschichte

In der Entwicklung eines Parsers versuchte der Entwickler, gleichzeitig eine veränderliche und eine unveränderliche Referenz auf einen Buffer zu speichern, um das Lesen und Schreiben zu optimieren. Infolgedessen kompilierte der Code nicht, und nach einem "Umgehen" der Regel durch unsafe traten Bugs mit Datenlecks auf.

Geschichte

Zu Beginn eines Datenverarbeitungsprojekts machte einer der Teilnehmer nicht "reanalyze borrow checker" für komplexen Code mit verschachtelten Bereichen. Infolgedessen trat aufgrund sich überschneidender Referenzen der klassische Fehler "cannot borrow as mutable because it's also borrowed as immutable" auf, ohne dass im Quellcode ein expliziter Hinweis auf die Problemstelle gegeben war.

Geschichte

In multithreaded Code wurden normale Referenzen verwendet, um auf gemeinsame Daten zuzugreifen. Bei dem Versuch, Daten in parallelen Threads zu ändern, traten unerwartete Kompilierungsfehler und Datenrennen auf, als der borrow checker durch unsicheren Code umgangen wurde.