Understanding Rust Closures

Understanding Rust Closures(antoine.vandecreme.net)

68 points by avandecreme 215 days ago | 34 comments

if I'm not mistaken (and I very well may be!) my primary confusion with closures comes from the fact that: the trait they implement (FnOnce / Fn / FnMut) depends entirely upon what happens inside the closure.

It will automatically implement the most general, relaxed version (FnMut I think?) and only restrict itself further to FnOnce and Fn based on what you do inside the closure.

So, it can be tricky to know what's going on, and making a code change can change the contract of the closure and therefore where and how it can be used.

(I invite rust experts to correct me if any of the above is mistaken - I always forget the order of precedence for FnOnce/Fn/FnMut and which implies which)

bobbylarrybobby 215 days ago | |

The three Fn* types correspond to the three ways you can refer to a value: &T, &mut T, T. Fn captures its environment by shared reference, FnMut by exclusive reference, and FnOnce by value, and everything flows from that. Calling a Fn is the same as using a reference. Calling a FnMut is the same as using a mutable reference (you can do it as many times as you want but no two uses may overlap in time). And calling a FnOnce is the same as moving a value (you can do it at most once).

School-Cotton 215 days ago | |

The least restrictive for the caller is Fn (you can call it whenever), then FnMut (you can call it only if you have exclusive access to it, as many times as you want), then FnOnce (you can call it only if you have exclusive owned access, and calling it once destroys it).

The least restrictive for the function itself is the opposite order: FnOnce (it can do anything to its environment, including possibly consuming things without putting them back into a consistent state), followed by FnMut (it has exclusive access to its environment, and so is allowed to mutate it, but not destroy it), followed by Fn (it has only shared access to its environment and therefore is not allowed to mutate it).

Since these orders are inverses of each other, functions that are easier to write are harder to call and vice versa. That’s why they implement the trait with the minimum amount of power possible, so that they can be called in more places.

yoshuaw 215 days ago | |

> I always forget the order of precedence for FnOnce/Fn/FnMut

The way I remember the ordering is by thinking about the restrictions the various Fn traits provide from a caller's perspective:

  1. FnOnce can only ever be called once and cannot be called concurrently. This is the most restrictive.

  2. FnMut can be called multiple times but cannot be called concurrently. This is less restrictive than FnOnce.

  3. Fn can be called multiple times and can even be called concurrently. This is the least restrictive.

So going from most to least restrictive gives you `FnMut: FnOnce` and `Fn: FnMut`.

School-Cotton 215 days ago | | |

Fn can only be called concurrently if its environment is Sync, which is often true but not necessarily.

It’s more precise to say that Fn can be called even when you only have shared access to it, which is a necessary, but not sufficient, condition for being able to be called concurrently.

csomar 214 days ago | |

My issue is that there is no easy way to know the signature generated by the closure (unlike a function) until you read the compiler errors and even then it's some cryptic mess because closures are anonymous structs. Or maybe I missed some LSP config/extension?

krukah 215 days ago | |

Easiest mnemonic to remember precedence is simply ordering by the length of their names.

FnOnce

FnMut

KolmogorovComp 215 days ago | |

This is correct. But it’s not really surprising, it’s type inference.

gpm 215 days ago | | |

It isn't really type inference. Each closure gets a unique type. Rather it's an automatic decision of what traits (think roughly "superclasses" I guess if you aren't familiar with traits/typeclasses) to implement for that type.

stevefan1999 214 days ago |

As a side note, there is a libffi wrapper on Rust that is exactly leveraging this code and data separation of closures in Rust: https://docs.rs/libffi

I've been using this on my vibewasm project to provide host function conversion to keep a C callable function in the front surface but doing my own custom wasm calling convention while capturing a persistent context pointer to the wasm store.

There is a side effect though: it is essentially unsound as you have to leak the object to the libffi closure which is a form of JIT -- dynamic code generation, it is, meaning Rust will have no way of knowing the lifetime of the pointer, or you have to always keep the libffi closure alive, meaning it is a permanent leak. I tried mitigate this by storing the closure in the wasm store, and we use that as the ultimate closure lifetime by designation -- any libffi function callback post store destruction is undefined behavior though.

BlackFly 214 days ago |

The biggest friction I experience with respect to rust closures is their inability to be generic: I cannot implement a method that takes a closure generic over its argument(s).

So then I'm forced to define a trait for the function, define a struct (the closure) to store the references I want to close over, choose the mutability and lifetimes, instantiate it manually and pass that. Then the implementation of the method (that may only be a few lines) is not located inline so readability may suffer.

tuetuopay 214 days ago | |

You most definitely can.

    fn foo<F, T>(f: F)
    where
        F: Fn(T),
        T: ToString,
    {
        f("Hello World")
    }

Or did I not understand what you meant?

armchairhacker 214 days ago | | |

Something like this isn’t possible

    fn foo(f: impl for<T: ToString> Fn(T)) {
        f(“Hello World”);
        f(3.14);
    }

    fn main() {
        f(|x| println!("{}", x.to_string());
    }

The workaround:

    trait FnToString {
        fn call(&self, x: impl ToString);
    }

    fn foo(f: impl FnToString) {
        f.call("Hello World");
        f.call(3.14);
    }

    struct AnFnToString;
    impl FnToString for AnFnToString {
        fn call(&self, x: impl ToString) {
            println!("{}", x.to_string());
        }
    }

    fn main() {
        foo(AnFnToString);
    }

wtetzner 214 days ago | |

Do you have an example of this? I'm not sure I follow it exactly.

OptionOfT 214 days ago |

I wish there was more customizability with regards to captures.

the move keywords captures everything. Sometimes I want a little bit more flexibility, like C++ lambdas.

avandecreme 214 days ago | |

This article discusses making captures more flexible: https://smallcultfollowing.com/babysteps/blog/2025/10/22/exp...

I agree it would be nice, in particular to make it easier to understand when learning the concept.

Sytten 215 days ago |

And now we have the Async version of each of those, which makes me very happy and reduces the shenanigans and lifetime issues.

Also worthy of note is that there is talk to add a syntax for explicit captures.

amelius 215 days ago |

Closures are the bread and butter of functional programming, but Rust made closures a complicated mess.

1. FnOnce can only ever be called once and cannot be called concurrently. This is the most restrictive. 2. FnMut can be called multiple times but cannot be called concurrently. This is less restrictive than FnOnce. 3. Fn can be called multiple times and can even be called concurrently. This is the least restrictive.

trait FnToString { fn call(&self, x: impl ToString); } fn foo(f: impl FnToString) { f.call("Hello World"); f.call(3.14); } struct AnFnToString; impl FnToString for AnFnToString { fn call(&self, x: impl ToString) { println!("{}", x.to_string()); } } fn main() { foo(AnFnToString); }