When Rust Closures Implement Fn, FnMut, and FnOnce

By the end of this page, you will understand how Rust decides whether a closure implements Fn, FnMut, and FnOnce. You will learn that every closure implements FnOnce, but only some also implement FnMut, and only a smaller set implement Fn. The key idea is how the closure uses its captured variables: moving values out limits it to FnOnce, mutating captured values allows FnMut but not Fn, and only read-only access allows Fn.

Rust closures automatically implement one, two, or all three of the closure traits based on how they use captured values.

The three traits form a ladder:

• Fn = can be called many times without mutating or consuming captured values
• FnMut = can be called many times, but may mutate captured values
• FnOnce = can be called at least once, and may consume captured values

A very important rule is:

• Every closure implements FnOnce

That means the answer to "When does a closure not implement FnOnce?" is:

• Never for normal closures

Why? Because any closure can always be called once by consuming the closure itself.

The core rule

Rust looks at what the closure body does with the variables it captures from the surrounding scope.

A closure implements Fn if

• it does not move captured values out of itself
• it does not mutably borrow or mutate captured values
• it only reads captured values, or captures nothing

A closure implements FnMut if

• it does not move captured values out of itself

Think of a closure as a small backpack that carries values from the surrounding scope.

When you call the closure, Rust asks: what does this closure do with the items in its backpack?

• Fn: it only looks at the items
• FnMut: it changes the items in the backpack
• FnOnce: it takes an item out permanently and uses it up

Analogy

Imagine a lunchbox:

• Fn opens the lunchbox, looks inside, maybe reads the label, then closes it unchanged
• FnMut opens the lunchbox and rearranges or modifies what is inside
• FnOnce opens the lunchbox and eats the sandwich, so the same lunchbox content cannot be used the same way again

That is why FnOnce may be callable only once: the closure may consume part of its captured state.

Basic syntax

The traits are usually seen in generic bounds:

fn call_fn<F: Fn()>(f: F) {
    f();
}

fn call_fnmut<F: FnMut()>(mut f: F) {
    f();
}

fn call_fnonce<F: FnOnce()>(f: F) {
    f();
}

Example 1: Closure that implements Fn

fn main() {
    let name = String::from("Rust");

    let print_name = || println!("Hello, {name}!");

    print_name();
    print_name();
}

This closure only reads name.

• It does not mutate name
• It does not move out of the closure

Consider this closure:

fn main() {
    let mut total = 0;

    let mut add_one = || {
        total += 1;
        println!("total = {total}");
    };

    add_one();
    add_one();
}

Step-by-step

1. total is created

let mut total = 0;

A mutable integer exists in the surrounding scope.

2. The closure is created

let mut add_one = || {
    total += 1;
    println!("total = {total}");
};

Rust sees that the closure uses total and captures it.

Because the closure does this:

1. Read-only callbacks with Fn

Use Fn when a callback should be safe to call many times without changing its environment.

Examples:

• formatting log messages
• checking whether a feature flag is enabled
• filtering items using shared read-only configuration

fn run_twice<F: Fn()>(f: F) {
    f();
    f();
}

2. Stateful processing with FnMut

Use FnMut when the closure needs to keep or update state between calls.

Examples:

• counting how many items were processed
• building up metrics
• assigning sequence numbers
• caching simple intermediate state

let mut count = 0;
let mut process = |_| {
    count += 1;
};

This is common in iterator pipelines.

3. One-time ownership transfer with FnOnce

In real Rust projects, developers choose closure trait bounds based on how often the callback should be reusable and whether it needs state.

Common patterns

Guard-like read-only checks use Fn

fn validate_with<F: Fn(&str) -> bool>(input: &str, check: F) -> bool {
    check(input)
}

This is useful for:

• validation rules
• predicates
• configuration checks
• access-control checks

Iteration counters and accumulators use FnMut

Many iterator methods accept FnMut because the closure is called multiple times and often updates state.

fn main() {
    let items = vec![1, 2, 3];
    let mut sum = 0;

    items.iter().for_each(|x| {
        sum += x;
    });

    ();
}

Mistake 1: Thinking some closures do not implement FnOnce

This is the biggest misconception.

let x = 5;
let c = || println!("{x}");

This closure implements FnOnce too.

Rule

• All closures implement FnOnce
• Some also implement FnMut
• Some also implement Fn

Mistake 2: Assuming move means only FnOnce

Broken assumption:

let x = String::from("hello");
let c = move || println!("{x}");

Beginners often think this must be FnOnce only.

Closure traits compared

Relationship between the traits

Quick rules

• Every closure implements FnOnce
• A closure implements FnMut if it does not move captured values out of itself
• A closure implements Fn if it does not mutate captured values and does not move them out

Easy way to decide

Ask these questions in order:

1. Does the closure move a captured value out when called?
   • Yes -> only FnOnce
   • No -> continue
2. Does the closure mutate captured state?
   • Yes -> FnMut and FnOnce
   • No -> Fn, FnMut, and FnOnce

Trait ladder

Fn -> FnMut -> FnOnce

Meaning:

• anything that is Fn can be used where FnMut is expected
• anything that is FnMut can be used where is expected

Does every Rust closure implement FnOnce?

Yes. Every closure can be called at least once by consuming the closure value itself.

When does a closure implement only FnOnce?

When calling it moves a captured value out of the closure or otherwise consumes captured state.

Why does mutating captured state prevent Fn?

Because Fn is called through an immutable reference. If the closure needs to change its captured environment, immutable access is not enough.

Does move always make a closure FnOnce?

No. A move closure can still implement Fn or FnMut if it does not consume captured values during the call.

Why do many iterator methods use FnMut?

Because they call the closure multiple times, and allowing mutation makes the API more useful for counters, accumulation, and local state.

Should I use Fn, FnMut, or FnOnce in my own function signatures?

Use the least restrictive bound that matches your function:

• Closures in Rust — The broader feature that includes capture rules, type inference, and anonymous functions.
• Ownership — Closure traits depend heavily on whether values are borrowed, mutated, or moved.
• Borrowing — Fn and FnMut are closely tied to immutable and mutable borrowing.
• Move closures — Important because move affects capture mode, which beginners often confuse with FnOnce.
• Traits — Fn, FnMut, and FnOnce are traits, so understanding trait bounds helps a lot.
• Generics — These closure traits are usually used in generic function signatures.
• Iterators — Many iterator methods accept closures, often with FnMut bounds.
• Lifetime and borrowing errors — Many closure-related compiler messages are really ownership and borrow-checking issues.