Rust Ownership und Borrowing im Überblick

Worum es geht

Das Rust-Buch nennt drei Regeln: Jeder Wert hat einen Owner, es kann zu jedem Zeitpunkt nur einen Owner geben, und wenn der Owner den Gültigkeitsbereich verlässt, wird der Wert verworfen. Das Zuweisen oder Übergeben eines heap-besitzenden Werts wie eines String verschiebt ihn; die alte Bindung danach zu verwenden ist ein Kompilierfehler, keine Überraschung zur Laufzeit. Typen, die vollständig auf dem Stack leben (Integers, bool, char, Tupel davon), implementieren Copy und werden stattdessen dupliziert, und .clone() erzeugt eine explizite tiefe Kopie. Eine Referenz (&T oder &mut T) leiht einen Wert, ohne den Besitz zu übernehmen; das Buch nennt zwei Regeln für Referenzen: zu jedem gegebenen Zeitpunkt entweder eine veränderliche Referenz oder beliebig viele unveränderliche Referenzen, und Referenzen müssen stets gültig sein. Der Borrow Checker des Compilers weist eine Referenz zurück, die ihren Wert überleben würde (eine hängende Referenz), sowie eine Mutation, während eine gemeinsame Referenz lebt. Das Buch stellt dem Sprachen mit Garbage Collector gegenüber, bei denen der Collector nicht mehr genutzten Speicher aufspürt.

Warum es wichtig ist

Wer von Python oder JavaScript kommt: Dort wird jedes Objekt per Referenz geteilt und vom Collector freigegeben; Aliasing plus Mutation sind normal und gelegentlich ein Fehler. Die Regeln von Rust machen genau diese Fehlerklasse, zusammen mit Iterator-Invalidierung und Data Races, zu Kompilierfehlern. Der Preis ist, dass Muster, die vorher nichts kosteten (zwei Strukturen, die dasselbe Objekt halten, eine Methode, die eine Referenz in ein Temporärobjekt zurückgibt), eine bewusste Entscheidung erfordern.

So wird es angewendet

• Standardmässig Referenzen übergeben: &T zum Lesen und &mut T für In-place-Änderungen; Besitz nur übergeben, wenn die aufgerufene Funktion den Wert behalten muss.
• Aus Konstruktoren und Parsern eigene (owned) Werte zurückgeben; Referenzen nur zurückgeben, wenn das Ergebnis von einem Argument leiht, und den Compiler nach einer Lifetime-Annotation fragen lassen, wenn er die Verbindung nicht ableiten kann.
• Rc<T> (einzelner Thread) oder Arc<T> (über Threads geteilt) verwenden, wenn tatsächlich mehrere Owner nötig sind, und RefCell oder Mutex, wenn geteilte Daten auch verändert werden müssen.
• Beschwert sich der Checker, zuerst umstrukturieren (die Ausleihe verkürzen, einen kleinen Wert klonen, eine Struct in unabhängig ausleihbare Teile aufteilen), bevor zu unsafe gegriffen wird.

Stolpersteine

Ein & in einen Vec halten, während in ihn gepusht wird. Eine Sammlung dem Wert nach zu iterieren (for x in v) verschiebt sie; über &v iterieren, um sie zu behalten. Referenzen in einer Struct zu speichern macht die Struct generisch über eine Lifetime. clone() auf grossen Daten aufzurufen, um den Checker zum Schweigen zu bringen, verdeckt das Designproblem, statt es zu beheben.