La storia della domanda origina dalla decisione di Rust di implementare le chiusure come astrazioni a costo zero tramite strutture anonime piuttosto che oggetti funzione con raccolta dei rifiuti. A differenza di linguaggi come JavaScript o Python, Rust deve codificare regole di proprietà, prestito e mutabilità direttamente nel tipo della chiusura. I tre tratti — Fn, FnMut e FnOnce — formano una rigida gerarchia basata sul parametro self nei loro metodi call, consentendo al compilatore di verificare a tempo di compilazione che l'uso di una chiusura rispetti gli invarianti di sicurezza della memoria del suo ambiente catturato.
Il problema si concentra sulla distinzione tra come una chiusura cattura le variabili (per riferimento o per valore tramite move) e come le utilizza internamente. FnOnce richiede self (consumando la proprietà), consentendo alla chiusura di spostare le variabili catturate dal suo ambiente ma limitandola a una sola invocazione. FnMut richiede &mut self, consentendo la mutazione dello stato catturato ma richiedendo accesso unico alla chiusura stessa. Fn richiede &self, abilitando più invocazioni simultanee ma vietando la mutazione delle variabili catturate, a meno che non venga utilizzata la mutabilità interna. Una chiusura che sposta un tipo non-Copy nel suo corpo diventa FnOnce perché la prima invocazione lascerebbe l'ambiente in uno stato traslocato, invalidando le chiamate successive. I candidati spesso confondono la parola chiave move — che costringe semplicemente la cattura per valore — con il tratto FnOnce, non riconoscendo che una chiusura move contenente solo tipi Copy implementa comunque Fn.
La soluzione implica la selezione del vincolo di tratto meno restrittivo necessario per l'API. Se la chiusura viene invocata esattamente una volta, utilizzare FnOnce per accettare la più ampia varietà di chiusure (inclusi quelli che consumano il loro ambiente). Se sono necessarie più invocazioni con mutazione, utilizzare FnMut. Per accesso ripetuto o concorrente in sola lettura, usare Fn. Il compilatore deriva automaticamente queste implementazioni in base all'analisi della cattura, senza richiedere implementazione manuale del tratto.
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 non è Copy apply_once(consume); let mut count = 0; let mut increment = || { count += 1; }; // FnMut: andamenti catturati apply_mut(&mut increment); let value = 42; let print = move || println!("{}", value); // Fn: i32 è Copy apply_fn(print); apply_fn(print); // Valido: print è Fn
Considera un pianificatore di attività asincrone in un server web ad alta capacità che accetta hook definiti dall'utente per elaborare le richieste in arrivo. L'API del pianificatore richiedeva inizialmente che tutti gli hook implementassero Fn per consentire una potenziale esecuzione parallela.
Descrizione del problema: Una nuova funzionalità richiedeva che gli hook mantenessero statistiche per connessioni individuali, necessitando la mutazione di contatori catturati. Gli sviluppatori tentarono di passare chiusure move che catturavano variabili mut counter, ma il compilatore rifiutò queste perché Fn richiede &self, che non può mutare i campi mut posseduti senza mutabilità interna. Il team si trovò di fronte a una scelta tra allentare il vincolo del tratto o ristrutturare la firma dell'hook.
Soluzione 1: Mutabilità interna con tipi atomici:
Sostituire il contatore u64 con AtomicU64 e catturarlo tramite Arc. La chiusura implementa Fn perché la mutazione avviene tramite operazioni atomiche su &self, richiedendo nessun accesso mutabile alla chiusura stessa.
Pro: Mantiene il vincolo Fn, consente al pianificatore di eseguire hook simultaneamente da più thread senza sincronizzazione sulla chiusura stessa.
Contro: Introduce un sovraccarico atomico a livello hardware e complessità nell'ordinamento della memoria. Richiede l'allocazione di Arc anche per l'uso a thread singolo, sconfiggendo i principi di astrazione a costo zero per contatori semplici.
Soluzione 2: Vincolo FnMut con esecuzione sequenziale:
Cambiare l'API del pianificatore per accettare chiusure FnMut. Il pianificatore memorizza gli hook in un Vec<Box<dyn FnMut()>> e li invoca sequenzialmente mentre detiene accesso &mut.
Pro: Zero sovraccarico di runtime per la mutazione. Garanzia a tempo di compilazione che non si verifichino race di dati, poiché il sistema di tipi impone accesso unico durante l'invocazione.
Contro: Impedisce l'invocazione concorrente dello stesso hook e complica la memorizzazione interna del pianificatore (richiede &mut self sul pianificatore stesso). Rovina la compatibilità con gli hook Fn esistenti a meno di utilizzare implementazioni generali.
Soluzione scelta: La soluzione 2 (FnMut) è stata selezionata perché l'architettura del server elaborava le connessioni per thread, eliminando la necessità di esecuzione concorrente degli hook. Il team ha preferito la sicurezza a tempo di compilazione rispetto alla flessibilità degli hook concorrenti, accettando il cambiamento dell'API come un'evoluzione corretta ma rompente.
Risultato: Il pianificatore ha gestito con successo gli hook stateful senza sovraccarico a runtime. Il sistema di tipi ha prevenuto un bug sottile in cui due thread avrebbero potuto retrocedere un contatore non atomico in modo concorrente, il che sarebbe stato possibile se RefCell fosse stato utilizzato con Fn senza corretta sincronizzazione.
La parola chiave move nella definizione di una chiusura rende automaticamente quella chiusura implementare FnOnce invece di Fn o FnMut?
No. La parola chiave move indica solo che le variabili catturate vengono spostate nell'ambiente della chiusura per valore, piuttosto che essere prestate. L'implementazione del tratto dipende esclusivamente da come il corpo della chiusura utilizza le sue catture. Se la chiusura sposta un tipo non-Copy dal suo ambiente (consumandolo), implementa FnOnce. Se muta solo le catture, implementa FnMut. Se legge o utilizza solo tipi Copy per valore, implementa Fn, anche con la parola chiave move. Ad esempio, let x = 5; let f = move || x + 1; implementa Fn perché i32 è Copy.
Perché una funzione che accetta FnOnce può essere chiamata con una chiusura che implementa Fn, ma non viceversa?
Fn è un sottotipo di FnMut, che è un sottotipo di FnOnce. Ciò significa che ogni chiusura che implementa Fn implementa automaticamente FnMut e FnOnce, ma il contrario non è vero. Un parametro di funzione vincolato da FnOnce accetta qualsiasi chiusura che può essere chiamata una sola volta, che include quelle che possono essere chiamate più volte (Fn e FnMut). Al contrario, una funzione che richiede Fn richiede che la chiusura supporti l'invocazione tramite un riferimento condiviso (&self), cosa che le chiusure che consumano il loro ambiente (FnOnce solo) non possono soddisfare. Questo segue il sottotipo standard: un tipo più capace (Fn) può essere usato dove è richiesto un tipo meno capace (FnOnce).
Come determina il compilatore quale tratto implementa una chiusura quando cattura riferimenti a variabili nell'ambito circostante?
Il compilatore analizza il corpo della chiusura per vedere come vengono accedute le variabili catturate. Se la chiusura sposta fuori una variabile catturata (e il tipo non è Copy), implementa FnOnce. Se muta una variabile catturata (assegna a essa o chiama metodi &mut self), implementa FnMut (e FnOnce). Se legge solo la variabile o chiama metodi &self, implementa Fn (e gli altri). Per le catture per riferimento (&T o &mut T), la chiusura detiene riferimenti. Se cattura &mut T, implementa tipicamente FnMut poiché la chiamata richiede accesso unico alla chiusura stessa per mantenere l'unicità del prestito mutabile. Se cattura &T, implementa Fn.