How to fix Rust E0277 the trait Fn is not implemented

Compiler Errors
2026-04-17T12:05:42+00:00
E0277 with the Fn trait means the value you passed isn't callable in the way the function asked. Walk through the four common shapes of this error and fix each one without flailing at the compiler.

What the compiler is actually telling you

You wrote a function that takes a closure. You handed it something. The compiler shrugs and says:

error[E0277]: the trait bound `T: Fn(i32) -> i32` is not satisfied
 --> src/main.rs:9:11
  |
9 |     apply(thing);
  |     ----- ^^^^^ the trait `Fn(i32) -> i32` is not implemented for `T`
  |     |
  |     required by a bound introduced by this call

E0277 is the generic "you didn't satisfy this trait bound" error. When the trait in question is Fn, FnMut, or FnOnce, it always means the same thing: you tried to call a value as a function, but the type system doesn't think it can be called the way you're using it.

The fix is almost never to change the function. It's to give the function something callable, with the right signature, and the right capture mode.

Three flavours of callable

Rust has three closure traits, in a hierarchy from most permissive to most restrictive:

  • Fn(Args) -> Ret is callable many times by shared reference (&self). It can read captured values but can't mutate them or move them out.
  • FnMut(Args) -> Ret is callable many times by exclusive reference (&mut self). It can mutate what it captured.
  • FnOnce(Args) -> Ret is callable exactly once (consumes self). It can move captured values out.

Every closure auto-implements as many of these as its body allows. A closure that only reads captures implements all three. A closure that mutates implements FnMut and FnOnce, but not Fn. A closure that moves a captured value out implements only FnOnce.

When the compiler complains, the trait it names is the strictest one your function asked for. If your function declared F: Fn, but you passed a closure that mutates, you'll see E0277: Fn is not implemented. The closure satisfies FnMut, just not Fn.

The smallest reproduction

// Generic over F. The bound F: Fn(i32) -> i32 says "F is callable
// many times via shared reference, takes one i32, returns one i32".
fn apply<F>(f: F) -> i32
where
    F: Fn(i32) -> i32,
{
    f(5)
}

fn main() {
    // A simple closure that captures nothing. Implements Fn, FnMut, and FnOnce.
    let add_one = |x| x + 1;

    // This compiles. The closure matches the Fn(i32) -> i32 bound exactly.
    println!("{}", apply(add_one));
}

That's the happy path. Now let's see how each flavour of E0277 shows up.

Case 1: wrong signature

fn apply<F: Fn(i32) -> i32>(f: F) -> i32 {
    f(5)
}

fn main() {
    // Closure takes &str, not i32. Signature mismatch.
    let stringify = |x: i32| x.to_string();

    // E0271/E0277: expected i32, found String for the return type.
    apply(stringify);
}

The fix is the obvious one. Match the signature, or change apply's bound to match what you're passing.

Case 2: passed a non-callable

fn apply<F: Fn(i32) -> i32>(f: F) -> i32 {
    f(5)
}

fn main() {
    let n: i32 = 7;

    // E0277: i32 is not a function. The compiler can't call it.
    apply(n);
}

You'd be surprised how often this comes up after a refactor. Someone removed the closure that wrapped a value, the value itself remains, and now you're passing a number to a function expecting a function.

Case 3: closure mutates, function asked for Fn

fn apply<F: Fn(i32) -> i32>(f: F) -> i32 {
    // The bound `Fn` lets us call f through &f. Many calls allowed.
    f(5)
}

fn main() {
    let mut count = 0;

    // This closure increments `count` every time it's called. That makes
    // it FnMut, not Fn. Fn requires the closure to be callable through
    // a shared reference, but mutating a captured variable needs &mut self.
    let counter = |x| {
        count += 1;
        x + count
    };

    // E0277: closure implements `FnMut`, not `Fn`.
    apply(counter);
}

The compiler error here is unusually friendly:

error[E0277]: expected a closure that implements the `Fn` trait,
              but this closure only implements `FnMut`

Two ways to fix it. Either relax the bound on apply to FnMut, or rewrite the closure not to mutate (in this toy example, return x + 1 and increment count outside).

// Fix 1: ask for FnMut, take by &mut so we can call it many times.
fn apply<F: FnMut(i32) -> i32>(mut f: F) -> i32 {
    f(5)
}

Note the mut f. To call an FnMut closure, the binding holding it must be mutable. The compiler will tell you if you forget.

Case 4: closure moves a value, function asked for Fn or FnMut

fn apply<F: Fn() -> String>(f: F) -> String {
    f()
}

fn main() {
    let s = String::from("hello");

    // `move` forces the closure to take ownership of `s`. The body
    // returns `s` directly, which moves it out of the closure. After
    // one call, `s` is gone. So this closure can only be called once.
    let take_it = move || s;

    // E0277: expected `Fn`, but found `FnOnce`.
    apply(take_it);
}

The fix is to use FnOnce if a single call is enough:

fn apply<F: FnOnce() -> String>(f: F) -> String {
    f()
}

If you genuinely need to call the closure many times, you can't move the captured value out. Clone it inside the closure body instead, or hold a reference to it.

When the function takes a function pointer

If you wrote fn apply(f: fn(i32) -> i32), you're not asking for a closure at all. fn(...) is the function-pointer type, and only closures that capture nothing convert to it automatically. A closure with captures will fail with E0277 against the fn pointer:

fn apply(f: fn(i32) -> i32) -> i32 {
    f(5)
}

fn main() {
    let bias = 10;
    // Captures `bias`. Cannot become a plain fn pointer.
    let f = |x| x + bias;

    // E0308 / E0277: expected fn item, found closure.
    apply(f);
}

The fix is almost always to switch the parameter to a generic with a closure trait bound, or to a boxed dyn Fn:

// Generic version (zero-cost, monomorphises per closure type).
fn apply<F: Fn(i32) -> i32>(f: F) -> i32 { f(5) }

// Trait object version (heap allocation, dynamic dispatch).
fn apply(f: Box<dyn Fn(i32) -> i32>) -> i32 { f(5) }

Use the generic form by default. Reach for Box<dyn Fn> only when you need to store callbacks of different concrete types in the same collection.

A debugging recipe

Whenever you see E0277 mentioning Fn, walk through this checklist:

  1. Read the trait the compiler wants. Is it Fn, FnMut, or FnOnce?
  2. Read what your closure actually implements. The error usually tells you on the next line.
  3. Either relax the function's bound, or change what the closure captures.
  4. If you're using a fn pointer, switch to a generic closure bound.

Most occurrences of this error fall into one of those four cases. The compiler is genuinely trying to help.

Where to go next