Rust Closures Practice: Fn, FnMut, FnOnce & Captures

The most common closure error. std::thread::spawn requires FnOnce + Send + 'static, so the closure must own everything it captures:

// WRONG: closure borrows, but data won't live long enough
// let handle = {
//     let name = String::from("Alice");
//     std::thread::spawn(|| println!("{name}"))  // error[E0373]
// };

// RIGHT: move ownership into the closure
let handle = {
    let name = String::from("Alice");
    std::thread::spawn(move || println!("{name}"))
};
handle.join().unwrap();

The move keyword forces the closure to take ownership of all captured variables, even if a borrow would suffice for the closure body. This satisfies the 'static lifetime bound. If you're coming from Python, closures work quite differently; see Python vs Rust functions compared for a side-by-side breakdown.

Without move, closures capture by the least restrictive mode the body requires:

1. Immutable borrow (&T) — if the closure only reads the value
2. Mutable borrow (&mut T) — if the closure mutates the value
3. Move (T) — if the closure consumes the value (e.g., drops it, returns it, moves it into another binding)

move overrides this: every capture becomes by-value. For Copy types, that means a copy. For owned types, that means a move.

let x = 10;           // Copy type
let s = String::from("hi"); // non-Copy type

let f = move || {
    println!("{x}");  // x is copied in
    println!("{s}");  // s is moved in
};
f();
println!("{x}");      // fine — x was copied
// println!("{s}");   // ERROR: s was moved into the closure

A common misconception. The move keyword controls how values get into the closure. The Fn/FnMut/FnOnce trait depends on what the closure body does with those values:

let name = String::from("Alice");

// move + only reads capture → implements Fn (callable many times)
let greet = move || println!("Hello, {name}");
greet();
greet(); // fine — name is read, not consumed

// move + consumes capture → implements FnOnce (callable once)
let consume = move || {
    drop(name);  // name is consumed
};
consume();
// consume(); // ERROR: cannot call FnOnce again

Every closure implements one or more of these traits. The hierarchy: Fn ⊂ FnMut ⊂ FnOnce.

// Fn: borrows immutably, callable many times
let x = 10;
let add_x = |n| n + x;
println!("{} {}", add_x(1), add_x(2));

// FnMut: borrows mutably, callable many times
let mut count = 0;
let mut inc = || count += 1;
inc();
inc();

// FnOnce: takes ownership, callable once
let name = String::from("Alice");
let greet = || {
    let owned = name;  // moves name out — consumes it
    println!("Hello, {owned}");
};
greet();
// greet(); // ERROR: cannot call again, name was consumed

This happens when a function expects a reusable closure but your closure consumes a captured value:

// WRONG: closure moves name out, so it's FnOnce
// fn repeat(f: impl Fn()) {
//     f(); f();
// }
// let name = String::from("Alice");
// repeat(|| {
//     let owned = name;  // error[E0525]
//     println!("{owned}");
// });

// RIGHT: borrow instead of consuming
fn repeat(f: impl Fn()) {
    f(); f();
}
let name = String::from("Alice");
repeat(|| {
    println!("{name}");  // borrows — now it's Fn
});

If the closure must consume, change the bound to FnOnce or .clone() before capture.

Both the captured variable and the closure binding need mut:

// WRONG: variable and closure not declared mut
// let count = 0;
// let inc = || count += 1;  // error[E0596]
// inc();                    // error: inc is not mut

// RIGHT: both bindings are mut
let mut count = 0;
let mut inc = || count += 1;
inc();
inc();
println!("{count}"); // 2

Iterator adapters are where closures shine:

let nums = vec![1, 2, 3, 4, 5];

// map: transform each element
let doubled: Vec<i32> = nums.iter().map(|&x| x * 2).collect();

// filter: keep elements matching a predicate
let evens: Vec<&i32> = nums.iter().filter(|&&x| x % 2 == 0).collect();

// fold: accumulate into a single value
let sum = nums.iter().fold(0, |acc, x| acc + x);

// chaining: filter then map
let big_doubled: Vec<i32> = nums.iter()
    .filter(|&&x| x > 2)
    .map(|&x| x * 2)
    .collect();

Closures that capture nothing can coerce to function pointers (fn). Closures that capture cannot:

// Works: no captures, coerces to fn
let add: fn(i32, i32) -> i32 = |a, b| a + b;

// ERROR: captures x, cannot coerce to fn
// let x = 10;
// let add_x: fn(i32) -> i32 = |n| n + x;

// RIGHT: use impl Fn or generics instead
fn apply(f: impl Fn(i32) -> i32, n: i32) -> i32 { f(n) }
let x = 10;
let result = apply(|n| n + x, 5); // 15

If an API requires fn(), make sure your closure captures nothing. If it must capture, the API needs to accept impl Fn() or Box<dyn Fn()>. The traits and generics guide covers how Fn, FnMut, and FnOnce work as trait bounds in generic functions.

Since edition 2021, closures capture individual fields instead of the whole struct:

struct Config { name: String, retries: u32 }
let config = Config { name: "app".into(), retries: 3 };

// Rust 2021: captures only config.retries, not all of config
let get_retries = || config.retries;

// config.name is still usable here
println!("{}", config.name);

In edition 2018, this would fail because the closure captured all of config. If you need the old behavior, use move or capture a reference to the whole struct explicitly. Closures accepting trait-bounded behaviors enable the Strategy design pattern -- select an algorithm at runtime by passing different closures.

• The Rust Book: Closures — capture modes, Fn traits, iterator patterns
• Rust Reference: Closure Types — precise capture rules
• Rust Edition Guide: Disjoint Capture — 2021 field-level captures
• Advanced Functions & Closures — function pointers, returning closures