Die Geschichte der Frage stammt aus Rusts Entscheidung, Closures als Null-Kosten-Abstraktionen über anonyme Strukturen anstelle von Garbage-Collector-Funktionsobjekten zu implementieren. Im Gegensatz zu Sprachen wie JavaScript oder Python muss Rust Eigentum, Ausleihen und Änderungsregeln direkt in den Typ der Closure kodieren. Die drei Traits—Fn, FnMut und FnOnce—bilden eine strenge Hierarchie basierend auf dem self-Parameter in ihren call-Methoden, wodurch der Compiler zur Compile-Zeit überprüfen kann, dass die Nutzung einer Closure die Speicher sicherheitlichen Invarianten ihrer erfassten Umgebung respektiert.
Das Problem dreht sich um die Unterscheidung, wie eine Closure Variablen erfasst (durch Referenz oder durch Wert über move) und wie sie sie intern verwendet. FnOnce erfordert self (besitzt das Eigentum), sodass die Closure erfasste Variablen aus ihrer Umgebung verschieben kann, was sie jedoch auf einen einzigen Aufruf beschränkt. FnMut erfordert &mut self, was eine Mutation des erfassten Zustands ermöglicht, aber einzigartigen Zugriff auf die Closure selbst fordert. Fn erfordert &self, was mehrere gleichzeitige Aufrufe ermöglicht, aber die Mutation erfasster Variablen verbietet, es sei denn, es wird innere Mutabilität verwendet. Eine Closure, die einen nicht-Copy-Typ in ihren Körper verschiebt, wird zu FnOnce, da der erste Aufruf die Umgebung in einen verschobenen Zustand versetzen würde, was nachfolgende Aufrufe ungültig macht. Kandidaten verwechseln oft das move-Schlüsselwort—das lediglich eine Erfassung durch Wert erzwingt—mit dem FnOnce-Trait, und erkennen nicht, dass eine move-Closure, die nur Copy-Typen enthält, immer noch Fn implementiert.
Die Lösung besteht darin, die am wenigsten einschränkende Trait-Beschränkung auszuwählen, die für die API erforderlich ist. Wenn die Closure genau einmal aufgerufen wird, verwenden Sie FnOnce, um die größte Vielfalt an Closures (einschließlich derjenigen, die ihre Umgebung konsumieren) zu akzeptieren. Wenn mehrere Aufrufe mit Mutation erforderlich sind, verwenden Sie FnMut. Für gleichzeitigen oder wiederholten schreibgeschützten Zugriff verwenden Sie Fn. Der Compiler leitet diese Implementierungen automatisch basierend auf der Erfassungsanalyse ab, was keine manuelle Trait-Implementierung erfordert.
fn apply_once<F: FnOnce()>(f: F) { f(); } fn apply_mut<F: FnMut()>(mut f: F) { f(); f(); } fn apply_fn<F: Fn()>(f: F) { f(); f(); } let data = vec![1, 2, 3]; let consume = move || drop(data); // FnOnce: Vec ist nicht Copy apply_once(consume); let mut count = 0; let mut increment = || { count += 1; }; // FnMut: mutiert Erfassung apply_mut(&mut increment); let value = 42; let print = move || println!("{}", value); // Fn: i32 ist Copy apply_fn(print); apply_fn(print); // Gültig: print ist Fn
Betrachten Sie einen asynchronen Aufgabenplaner in einem hochdurchsatzfähigen Webserver, der benutzerdefinierte Hooks akzeptiert, um eingehende Anfragen zu verarbeiten. Die API des Planers erforderte zunächst, dass alle Hooks Fn implementieren, um eine mögliche parallele Ausführung zu ermöglichen.
Problembeschreibung: Eine neue Funktion benötigte Hooks zur Aufrechterhaltung von Verbindungsstatistiken, was eine Mutation erfasster Zähler erforderte. Entwickler versuchten, move-Closures zu übergeben, die mut counter-Variablen erfassen, aber der Compiler wies diese zurück, da Fn &self erfordert, was keine Mutation eigener mut-Felder ohne innere Mutabilität zulässt. Das Team stand vor der Wahl, die Trait-Beschränkung zu lockern oder die Hook-Signatur umzugestalten.
Lösung 1: Innere Mutabilität mit atomaren Typen:
Ersetzen Sie den u64-Zähler durch AtomicU64 und erfassen Sie ihn über Arc. Die Closure implementiert Fn, da die Mutation durch atomare Operationen auf &self erfolgt und kein mutabler Zugriff auf die Closure selbst erforderlich ist.
Vorteile: Hält die Fn-Beschränkung aufrecht, ermöglicht dem Planer, Hooks von mehreren Threads ohne Synchronisierung auf die Closure selbst gleichzeitig auszuführen.
Nachteile: Führt Hardware-level atomare Overhead und Komplexität bei der Speicherordnung ein. Erfordert Arc-Allokation, selbst für den einthreadigen Gebrauch, was die Prinzipien der Null-Kosten-Abstraktion für einfache Zähler untergräbt.
Lösung 2: FnMut-Beschränkung mit sequenzieller Ausführung:
Ändern Sie die Scheduler-API, um FnMut-Closures zu akzeptieren. Der Scheduler speichert Hooks in einem Vec<Box<dyn FnMut()>> und ruft sie sequenziell auf, während er &mut-Zugriff hält.
Vorteile: Null Laufzeithardwareaufwand für Mutationen. Compile-Zeit-Garantie, dass keine Datenrennen auftreten, da das Typsystem während der Invocation einzigartigen Zugriff durchsetzt.
Nachteile: Verhindert die gleichzeitige Aufruf desselben Hooks und kompliziert den internen Speicher des Planers (erfordert &mut self auf dem Scheduler selbst). Bricht die Kompatibilität mit bestehenden Fn-Hooks, es sei denn, es werden generische Implementierungen verwendet.
Ausgewählte Lösung: Lösung 2 (FnMut) wurde ausgewählt, da die Architektur des Servers Verbindungen pro Thread verarbeitete und die Notwendigkeit einer gleichzeitigen Hook-Ausführung entfiel. Das Team bevorzugte die Sicherheit zur Compile-Zeit gegenüber der Flexibilität gleichzeitiger Hooks und akzeptierte die API-Änderung als eine Breaking, aber korrekte Evolution.
Ergebnis: Der Scheduler bearbeitete erfolgreich zustandsbehaftete Hooks ohne Laufzeitalaufwand. Das Typsystem verhinderte einen subtilen Fehler, bei dem zwei Threads möglicherweise gleichzeitig einen nicht-atomaren Zähler erhöht haben, was möglich gewesen wäre, wenn RefCell mit Fn ohne entsprechende Synchronisierung verwendet worden wäre.
Macht das move-Schlüsselwort in der Definition einer Closure diese Closure automatisch zu einer Implementierung von FnOnce anstelle von Fn oder FnMut?
Nein. Das move-Schlüsselwort legt nur fest, dass erfasste Variablen durch Wert in die Umgebung der Closure verschoben werden, anstatt ausgeliehen zu werden. Die Trait-Implementierung hängt ausschließlich davon ab, wie der Body der Closure seine Erfassungen verwendet. Wenn die Closure einen nicht-Copy-Typ aus ihrer Umgebung bewegt (verbraucht), implementiert sie FnOnce. Wenn sie nur Erfassungen mutiert, implementiert sie FnMut. Wenn sie nur liest oder Copy-Typen durch Wert verwendet, implementiert sie Fn, selbst mit dem move-Schlüsselwort. Zum Beispiel, let x = 5; let f = move || x + 1; implementiert Fn, da i32 Copy ist.
Warum kann eine Funktion, die FnOnce akzeptiert, mit einer Closure aufgerufen werden, die Fn implementiert, aber nicht umgekehrt?
Fn ist ein Subtrait von FnMut, das ein Subtrait von FnOnce ist. Das bedeutet, dass jede Closure, die Fn implementiert, automatisch FnMut und FnOnce implementiert, nicht umgekehrt. Ein Funktionsparameter, der durch FnOnce begrenzt ist, akzeptiert jede Closure, die einmal aufgerufen werden kann, also auch solche, die mehrfach aufgerufen werden können (Fn und FnMut). Umgekehrt verlangt eine Funktion, die Fn erfordert, dass die Closure die Invocation über eine geteilte Referenz (&self) unterstützt, was Closures, die ihre Umgebung konsumieren (FnOnce nur), nicht erfüllen können. Dies folgt dem Standard-Subtyping: Ein fähigerer Typ (Fn) kann verwendet werden, wo ein weniger fähiger (FnOnce) erforderlich ist.
Wie bestimmt der Compiler, welches Trait eine Closure implementiert, wenn sie Referenzen auf Variablen im umgebenden Scope erfasst?
Der Compiler analysiert den Closure-Körper, um zu sehen, wie erfasste Variablen zugegriffen werden. Wenn die Closure aus einer erfassten Variablen heraus verschiebt (und der Typ nicht Copy ist), implementiert sie FnOnce. Wenn sie eine erfasste Variable mutiert (ihr zuweist oder &mut self-Methoden aufruft), implementiert sie FnMut (und FnOnce). Wenn sie nur die Variable liest oder &self-Methoden aufruft, implementiert sie Fn (und die anderen). Bei Erfassungen durch Referenz (&T oder &mut T) hält die Closure Referenzen. Wenn sie &mut T erfasst, implementiert sie typischerweise FnMut, da ihr Aufruf einzigartigen Zugriff auf die Closure selbst erfordert, um die Einzigartigkeit der mutablen Ausleihe zu wahren. Wenn sie &T erfasst, implementiert sie Fn.