Antwort.

Die Geschichte der Frage

In Rust kapseln Typen häufig andere Werte (z. B. Box, Rc) ein, und Entwickler wünschten sich einen transparenten Zugriff auf die inneren Werte, ähnlich wie mit Zeigern in C++. Es wurde das Trait Deref (und DerefMut) und eine spezielle Logik für das Auto-Deref hinzugefügt, um den Zugriff über Methoden und Operatoren zu erleichtern.

Das Problem

Verwirrung darüber, wann und wie Zeiger und Smart Pointer automatisch dereferenziert werden, führt zu Kompilierungsfehlern, unerwartetem Verhalten von Methoden und manchmal sogar zu suboptimalem Code aufgrund unnötiger Kopien oder Verleihungen.

Die Lösung

Das Trait Deref ermöglicht es, eine eigene Dereferenzierungsregel zu definieren (z. B. verhält sich Box<T> wie T dank der Implementierung von Deref). Das Auto-Deref-System versucht, Verweise auf Deref-Typen beim Zugriff auf Methoden und Operatoren "aufzulösen". Dadurch ist es möglich, Folgendes zu schreiben:

use std::rc::Rc;

fn print_len(s: &str) {
    println!("{}", s.len());
}

let s: Rc<String> = Rc::new("hello".into());
print_len(&s); // auto-deref: &Rc<String> -> &String -> &str

Kernmerkmale:

Automatisches Dereferenzieren funktioniert beim Aufruf von Methoden und beim Operator *, sowie beim Musterabgleich von Referenztypen
Box, Rc, Arc implementieren Deref (und oft DerefMut) für den "transparenten" Zugriff
Deref-Coercion funktioniert nur für einseitige Umwandlungen

Fangfragen.

Findet auto-deref immer statt, wenn der Entwickler es "erwartet"?

Nein: Deref-Coercion findet nur beim Aufruf von Methoden oder wenn eine Referenz auf einen anderen Typ, der in der Signatur über Deref Target angegeben ist, erforderlich ist, statt. Es funktioniert nicht in allen Ausdrücken, z. B. beim Pattern Matching.

Kann Deref-Coercion die Regeln für Borrowing und Ownership brechen?

Nein. Deref-Coercion beachtet vollständig die Regeln für Borrowing – es ist unmöglich, zwei mutable Referenzen über Deref zu erhalten, was die Sicherheitsregeln von Rust verletzen würde.

Ist ein auto-deref von &T nach &U möglich, wenn T: Deref<Target=U> und beide Typen nicht explizit verbunden sind?

Ja, beim Aufruf einer Funktion, die &U erwartet, führt die Übergabe von &T, wo T Deref<Target=U> implementiert, zu einer automatischen Umwandlung.

Beispielcode:

struct Wrapper(String);

impl std::ops::Deref for Wrapper {
    type Target = String;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

fn takes_str(s: &str) {}
let w = Wrapper("mytext".into());
takes_str(&w); // auto-deref: &Wrapper -> &String -> &str

Typische Fehler und Anti-Pattern

Methoden schreiben, die &T erwarten, und T übergeben, ohne das Borrowing zu beachten
Erwarten, dass auto-deref dort funktioniert, wo es nicht angewendet wird (z. B. beim Destructuring)
Deref/DerefMut nicht implementieren, wenn eigene Smart Pointer-Strukturen erstellt werden

Beispiel aus der Praxis

Negativer Fall

Ein Entwickler hat seinen eigenen Smart Pointer implementiert, aber die Implementierung von Deref nicht hinzugefügt, in der Erwartung, dass sein Typ sich wie ein normales Wert verhält.

Vorteile:

Der Typ wird kompiliert und man kann explizit auf den inneren Wert zugreifen.

Nachteile:

Das auto-deref funktioniert nicht mehr beim Aufruf von Methoden, was die Verwendung von Standardbibliotheks- und Drittanbieterfunktionen erschwert.

Positiver Fall

Eine eigene Wrapper-Struktur implementiert Deref und DerefMut ähnlich wie Box, nahtlose Integration mit allen Standardfunktionen.