De geschiedenis van de vraag komt voort uit Rust's beslissing om closures te implementeren als zero-cost abstracties via anonieme structs in plaats van door garbage-collected functieobjecten. In tegenstelling tot talen zoals JavaScript of Python, moet Rust eigendom, lenen en mutabiliteitsregels direct in het type van de closure coderen. De drie traits—Fn, FnMut en FnOnce—vorming een strikte hiërarchie op basis van de self parameter in hun call methoden, waardoor de compiler kan verifiëren dat het gebruik van een closure tijdens de compileertijd de geheugenveiligheidsinvarianten van zijn gecapturde omgeving respecteert.
Het probleem draait om het onderscheid tussen hoe een closure variabelen vastlegt (via referentie of via waarde via move) en hoe het deze intern gebruikt. FnOnce vereist self (eigendom consumeren), waardoor de closure gecapturde variabelen uit zijn omgeving kan verplaatsen, maar beperkt is tot een enkele aanroep. FnMut vereist &mut self, waardoor mutatie van de gecapturde status mogelijk is, maar unieke toegang tot de closure zelf vereist. Fn vereist &self, waardoor meerdere gelijktijdige aanroepen mogelijk zijn, maar mutatie van gecapturde variabelen verbiedt, tenzij interne mutabiliteit wordt gebruikt. Een closure die een niet-Copy type in zijn body verplaatst, wordt FnOnce omdat de eerste aanroep de omgeving in een verplaatste toestand zou achterlaten, waardoor daaropvolgende aanroepen ongeldig worden. Kandidaten verwarren vaak het move sleutelwoord — dat alleen dwingt om per waarde vast te leggen — met de FnOnce trait, en erkennen niet dat een move closure die alleen Copy types bevat nog steeds Fn implementeert.
De oplossing houdt in dat de minst beperkende trait bound die nodig is voor de API wordt geselecteerd. Als de closure precies één keer wordt aangeroepen, gebruik dan FnOnce om de breedste verscheidenheid aan closures (inclusief diegene die hun omgeving consumeren) te accepteren. Als meerdere aanroepen met mutatie nodig zijn, gebruik dan FnMut. Voor gelijktijdige of herhaalde alleen-lezen toegang, gebruik Fn. De compiler afleidt automatisch deze implementaties op basis van capture-analyse, zonder dat handmatige trait-implementatie vereist is.
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 is niet Copy apply_once(consume); let mut count = 0; let mut increment = || { count += 1; }; // FnMut: mutatie van capture apply_mut(&mut increment); let value = 42; let print = move || println!("{}", value); // Fn: i32 is Copy apply_fn(print); apply_fn(print); // Geldig: print is Fn
Overweeg een asynchrone taakplanner in een hoogdoorvoer webserver die gebruikersgedefinieerde hooks accepteert om inkomende verzoeken te verwerken. De planner API vereiste aanvankelijk dat alle hooks Fn implementeerden om potentiële parallelle uitvoering toe te staan.
Probleembeschrijving: Een nieuwe functie vereiste dat hooks per-verbinding statistieken bijhielden, wat mutatie van gecapturde tellers vereiste. Ontwikkelaars probeerden move closures die mut counter variabelen vastlegden door te geven, maar de compiler wees deze af omdat Fn &self vereist, dat geen mutabele velden kan muteren zonder interne mutabiliteit. Het team stond voor de keuze tussen het versoepelen van de trait-bound of het herstructureren van de hook-handtekening.
Oplossing 1: Interne Mutabiliteit met Atomische Typen:
Vervang de u64 teller door AtomicU64 en capture het via Arc. De closure implementeert Fn omdat mutatie plaatsvindt via atomische operaties op &self, wat geen mutabele toegang tot de closure zelf vereist.
Voordelen: Behoudt de Fn bound, waardoor de planner hooks gelijktijdig van meerdere threads kan uitvoeren zonder synchronisatie op de closure zelf.
Nadelen: Introduceert hardware-niveau atomair overhead en complexiteit van geheugenordering. Vereist Arc-allocatie, zelfs voor enkel-gedraad gebruik, wat de principes van zero-cost abstracties voor eenvoudige tellers ondermijnt.
Oplossing 2: FnMut Bound met Sequentiële Uitvoering:
Verander de planner API om FnMut closures te accepteren. De planner slaat hooks op in een Vec<Box<dyn FnMut()>> en roept ze sequentieel aan terwijl het &mut toegang houdt.
Voordelen: Zero runtime overhead voor mutatie. Compileertijd garantie dat er geen dataraces optreden, aangezien het type systeem unieke toegang afdwingt tijdens de aanroep.
Nadelen: Voorkomt gelijktijdige aanroep van dezelfde hook en complicaties in de interne opslag van de planner (vereist &mut self op de planner zelf). Breekt compatibiliteit met bestaande Fn hooks, tenzij gebruik wordt gemaakt van blanket-implementaties.
Gekozen oplossing: Oplossing 2 (FnMut) werd geselecteerd omdat de architectuur van de server verbindingen per thread verwerkte, waardoor de noodzaak voor gelijktijdige hookuitvoering verviel. Het team gaf de voorkeur aan compileertijdveiligheid boven de flexibiliteit van gelijktijdige hooks en accepteerde de API-wijziging als een brekende maar correcte evolutie.
Resultaat: De planner handhaafde succesvol stateful hooks zonder runtime overhead. Het type systeem voorkwam een subtiele bug waarbij twee threads mogelijk een niet-atomische teller tegelijkertijd hadden kunnen verhogen, wat mogelijk zou zijn geweest als RefCell was gebruikt met Fn zonder juiste synchronisatie.
Maakt het move sleutelwoord in een closure-definitie automatisch dat die closure FnOnce implementeert in plaats van Fn of FnMut?
Nee. Het move sleutelwoord bepaalt alleen dat de gecapturde variabelen per waarde in de closure-omgeving worden verplaatst, in plaats van te worden geleend. De trait-implementatie hangt volledig af van hoe de closure body zijn captures gebruikt. Als de closure een niet-Copy type uit zijn omgeving verplaatst (het consumeert), implementeert het FnOnce. Als het alleen captures muteert, implementeert het FnMut. Als het alleen leest of Copy types per waarde gebruikt, implementeert het Fn, ook al is daar het move sleutelwoord bij betrokken. Bijvoorbeeld, let x = 5; let f = move || x + 1; implementeert Fn omdat i32 Copy is.
Waarom kan een functie die FnOnce accepteert worden aangeroepen met een closure die Fn implementeert, maar niet vice versa?
Fn is een subtrait van FnMut, dat op zijn beurt een subtrait van FnOnce is. Dit betekent dat elke closure die Fn implementeert automatisch FnMut en FnOnce implementeert, maar andersom niet waar is. Een functieverplichting die beperkt is door FnOnce accepteert elke closure die eenmaal kan worden aangeroepen, inclusief diegene die meerdere keren kunnen worden aangeroepen (Fn en FnMut). Omgekeerd vereist een functie die Fn vereist dat de closure ondersteuning biedt voor aanroep via een gedeelde referentie (&self), die closures die hun omgeving consumeren (FnOnce alleen) niet kunnen voldoen. Dit volgt de standaard subtyping: een capabele type (Fn) kan worden gebruikt waar een minder capabele type (FnOnce) vereist is.
Hoe bepaalt de compiler welke trait een closure implementeert wanneer deze referenties naar variabelen in de omringende scope vastlegt?
De compiler analyseert de closure-body om te zien hoe gecapturde variabelen worden benaderd. Als de closure een gecapturde variabele verplaatst (en het type is niet Copy), implementeert het FnOnce. Als het een gecapturde variabele muteert (deze toewijst of &mut self methoden aanroept), implementeert het FnMut (en FnOnce). Als het alleen de variabele leest of &self methoden aanroept, implementeert het Fn (en de anderen). Voor captures per referentie (&T of &mut T), houdt de closure referenties. Als het &mut T vastlegt, implementeert het doorgaans FnMut omdat het aanroepen unieke toegang tot de closure zelf vereist om de uniekheid van de mutabele leningen te behouden. Als het &T vastlegt, implementeert het Fn.