History of the question originates from Rust's decision to implement closures as zero-cost abstractions via anonymous structs rather than garbage-collected function objects. Unlike languages such as JavaScript or Python, Rust must encode ownership, borrowing, and mutability rules directly into the closure's type. The three traits—Fn, FnMut, and FnOnce—form a strict hierarchy based on the self parameter in their call methods, enabling the compiler to verify at compile time that a closure's usage respects the memory safety invariants of its captured environment.
The problem centers on the distinction between how a closure captures variables (by reference or by value via move) and how it uses them internally. FnOnce requires self (consuming ownership), permitting the closure to move captured variables out of its environment but restricting it to a single invocation. FnMut requires &mut self, allowing mutation of captured state but demanding unique access to the closure itself. Fn requires &self, enabling multiple concurrent invocations but forbidding mutation of captured variables unless interior mutability is used. A closure that moves a non-Copy type into its body becomes FnOnce because the first invocation would leave the environment in a moved-from state, invalidating subsequent calls. Candidates often conflate the move keyword—which merely forces capture by value—with the FnOnce trait, failing to recognize that a move closure containing only Copy types still implements Fn.
The solution involves selecting the least restrictive trait bound necessary for the API. If the closure is invoked exactly once, use FnOnce to accept the widest variety of closures (including those that consume their environment). If multiple invocations with mutation are required, use FnMut. For concurrent or repeated read-only access, use Fn. The compiler automatically derives these implementations based on capture analysis, requiring no manual trait implementation.
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 not Copy apply_once(consume); let mut count = 0; let mut increment = || { count += 1; }; // FnMut: mutates capture apply_mut(&mut increment); let value = 42; let print = move || println!("{}", value); // Fn: i32 is Copy apply_fn(print); apply_fn(print); // Valid: print is Fn
Consider an asynchronous task scheduler in a high-throughput web server that accepts user-defined hooks to process incoming requests. The scheduler API initially required all hooks to implement Fn to allow potential parallel execution.
Problem description: A new feature required hooks to maintain per-connection statistics, necessitating mutation of captured counters. Developers attempted to pass move closures capturing mut counter variables, but the compiler rejected these because Fn requires &self, which cannot mutate owned mut fields without interior mutability. The team faced a choice between relaxing the trait bound or restructuring the hook signature.
Solution 1: Interior Mutability with Atomic Types:
Replace the u64 counter with AtomicU64 and capture it via Arc. The closure implements Fn because mutation occurs through atomic operations on &self, requiring no mutable access to the closure itself.
Pros: Maintains the Fn bound, allows the scheduler to execute hooks concurrently from multiple threads without synchronization on the closure itself.
Cons: Introduces hardware-level atomic overhead and memory ordering complexity. Requires Arc allocation even for single-threaded use, defeating zero-cost abstraction principles for simple counters.
Solution 2: FnMut Bound with Sequential Execution:
Change the scheduler API to accept FnMut closures. The scheduler stores hooks in a Vec<Box<dyn FnMut()>> and invokes them sequentially while holding &mut access.
Pros: Zero runtime overhead for mutation. Compile-time guarantee that no data races occur, as the type system enforces unique access during invocation.
Cons: Prevents concurrent invocation of the same hook and complicates the scheduler's internal storage (requires &mut self on the scheduler itself). Breaks compatibility with existing Fn hooks unless using blanket implementations.
Chosen solution: Solution 2 (FnMut) was selected because the server's architecture processed connections per-thread, eliminating the need for concurrent hook execution. The team preferred compile-time safety over the flexibility of concurrent hooks, accepting the API change as a breaking but correct evolution.
Result: The scheduler successfully handled stateful hooks with no runtime overhead. The type system prevented a subtle bug where two threads might have concurrently incremented a non-atomic counter, which would have been possible if RefCell had been used with Fn without proper synchronization.
Does the move keyword in a closure's definition automatically make that closure implement FnOnce instead of Fn or FnMut?
No. The move keyword dictates only that captured variables are moved into the closure's environment by value, rather than being borrowed. The trait implementation depends solely on how the closure body uses its captures. If the closure moves a non-Copy type out of its environment (consuming it), it implements FnOnce. If it only mutates captures, it implements FnMut. If it only reads or uses Copy types by value, it implements Fn, even with the move keyword. For example, let x = 5; let f = move || x + 1; implements Fn because i32 is Copy.
Why can a function accepting FnOnce be called with a closure that implements Fn, but not vice versa?
Fn is a subtrait of FnMut, which is a subtrait of FnOnce. This means every closure implementing Fn automatically implements FnMut and FnOnce, but the reverse is not true. A function parameter bounded by FnOnce accepts any closure that can be called once, which includes those that can be called multiple times (Fn and FnMut). Conversely, a function requiring Fn demands the closure support invocation through a shared reference (&self), which closures consuming their environment (FnOnce only) cannot satisfy. This follows standard subtyping: a more capable type (Fn) can be used where a less capable one (FnOnce) is required.
How does the compiler determine which trait a closure implements when it captures references to variables in the enclosing scope?
The compiler analyzes the closure body to see how captured variables are accessed. If the closure moves out of a captured variable (and the type is not Copy), it implements FnOnce. If it mutates a captured variable (assigns to it or calls &mut self methods), it implements FnMut (and FnOnce). If it only reads the variable or calls &self methods, it implements Fn (and the others). For captures by reference (&T or &mut T), the closure holds references. If it captures &mut T, it typically implements FnMut because calling it requires unique access to the closure itself to maintain the uniqueness of the mutable borrow. If it captures &T, it implements Fn.