6 ms·

Understanding Rust Closures

68 points by avandecreme 8mo ago

amelius 8mo ago
Closures are the bread and butter of functional programming, but Rust made closures a complicated mess.
- Klonoar 8mo ago
  If you understand the borrow checker, closures are just not that much on top of things. In fact I can’t remember the last time I had to fight with them.
  - convolvatron 8mo ago
    I really wanted just yesterday to create a dyn AsyncFnMut, which apparently still needs async-trait to build the stable. but I was pretty much unable to figure out how to make that work with a lambda. saying this is all trivial once you understand the borrow machinery is really understating it.
    - kibwen 8mo ago
      > saying this is all trivial The comment above isn't saying that closures are trivial. Once you understand the borrow checker, you understand that it's a miracle that closures in Rust can possibly work at all, given Rust's other dueling goals of being a GC-less language with guaranteed memory safety despite letting closures close over arbitrary references. Rust is in uncharted territory here, drawing the map as it goes.
    - speed_spread 8mo ago
      Async is the stuff that messes up everything. Closures are not complicated.
  - SkiFire13 8mo ago
    Closures are pretty simple in relation to their captures lifetimes, but they do have a lot of complexity in how the lifetimes of their argument and return type are computed. The compiler has to basically infer them, and that can easily go very wrong. The only reason it works most of the time is because closures are immediately passed to functions whose trait bound specify the expected signature of the closure, but once you deviate a little bit from the common case things start to break down. For example if the bound is `F: SomeTrait` where `SomeTrait` is implemented for `FnOnce(&' i32) -> &i32` the inference will break. Similarly if you store the closure in a local variable before passing it to the function. This used to come up pretty often for "async" closures that were supposed to take a reference as input, since it's impossible to specify their correct trait bound using directly the `Fn*` traits. There are a bunch of related issues [1] in the rustc repo if you search for closure and higher ranked lifetimes. [1]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3A%22A-higher-ranked%22%20label%3A%22A-closures%22 https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3A...
- openuntil3am 8mo ago
  Closures are a complicated mess. Functional programming languages hide the mess with garbage collection.
  - andrewflnr 8mo ago
    This isn't the right framing IMO. Closures actually aren't complicated with GC for the same reason structs with references aren't complicated, at least as far as the programmer is concerned. You could say functional languages "hide the mess" there too, but even if you take that perspective, it's nothing to do with closures in particular. Closures are just one of the things that need memory, and memory management is tricky without GC.
  - armchairhacker 8mo ago
    Machine code and LLVM are complicated messes. Higher-level language hide a lot, but sometimes issues pop up, even in Rust e.g. inline heuristics (https://nnethercote.github.io/perf-book/inlining.html https://nnethercote.github.io/perf-book/inlining.html).
- ordu 8mo ago
  Well... Rust is not a functional language, so it is not surprising that its closures are complicated.
- SkiFire13 8mo ago
  Functional programming languages usually don't support linear/affine types, non-gc references and mutations. Their closures are essentially the equivalent of Rust's `Rc<dyn Fn(...) -> ...>` with some sugar for expressing the function type and hiding all the `.clone()`s needed. It's easy to get simplier results if you support less features and use cases.
andy_xor_andrew 8mo ago
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)
- KolmogorovComp 8mo ago
  This is correct. But it’s not really surprising, it’s type inference.
  - gpm 8mo 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.
    - chowells 8mo ago
      So you're saying... it's type inference of type classes, just like in Haskell?
      - csomar 8mo ago
        I am not sure how Haskell works but I think what the previous poster meant is that the types get determined at compile time. Closures are akin to macros except you can't see the expanded code.
      - gpm 8mo ago
        No, I don't think so, not unless there's some feature of Haskell type classes I'm completely unaware of. If anything it's closer to SFINAE in C++ where it tries to implement methods but then doesn't consider it an error if it fails. Then infers type-classes based on the outcome of the SFINAE process. Or the macro analogy another poster made isn't bad (with the caveat that it's a type system aware macro - which at least in rust is strange).
Sytten 8mo 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.
deleted 8mo ago
[deleted]
OptionOfT 8mo 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 8mo ago
  This article discusses making captures more flexible: https://smallcultfollowing.com/babysteps/blog/2025/10/22/explicit-capture-clauses/ 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.
BlackFly 8mo 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.
- wtetzner 8mo ago
  Do you have an example of this? I'm not sure I follow it exactly.
- tuetuopay 8mo 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 8mo 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); }
    - tuetuopay 8mo ago
      Ha, yes, I see what you mean now. That's not really the closure's fault but monomorphization of the foo function. The specific thing you want to do would require boxing the value, or do more involved typing.
stevefan1999 8mo 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 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.

68 points by avandecreme 8mo ago

amelius 8mo ago

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

Klonoar 8mo ago
If you understand the borrow checker, closures are just not that much on top of things. In fact I can’t remember the last time I had to fight with them.
- convolvatron 8mo ago
  I really wanted just yesterday to create a dyn AsyncFnMut, which apparently still needs async-trait to build the stable. but I was pretty much unable to figure out how to make that work with a lambda. saying this is all trivial once you understand the borrow machinery is really understating it.
  - kibwen 8mo ago
    > saying this is all trivial The comment above isn't saying that closures are trivial. Once you understand the borrow checker, you understand that it's a miracle that closures in Rust can possibly work at all, given Rust's other dueling goals of being a GC-less language with guaranteed memory safety despite letting closures close over arbitrary references. Rust is in uncharted territory here, drawing the map as it goes.
  - speed_spread 8mo ago
    Async is the stuff that messes up everything. Closures are not complicated.
- SkiFire13 8mo ago
  Closures are pretty simple in relation to their captures lifetimes, but they do have a lot of complexity in how the lifetimes of their argument and return type are computed. The compiler has to basically infer them, and that can easily go very wrong. The only reason it works most of the time is because closures are immediately passed to functions whose trait bound specify the expected signature of the closure, but once you deviate a little bit from the common case things start to break down. For example if the bound is `F: SomeTrait` where `SomeTrait` is implemented for `FnOnce(&' i32) -> &i32` the inference will break. Similarly if you store the closure in a local variable before passing it to the function. This used to come up pretty often for "async" closures that were supposed to take a reference as input, since it's impossible to specify their correct trait bound using directly the `Fn*` traits. There are a bunch of related issues [1] in the rustc repo if you search for closure and higher ranked lifetimes. [1]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3A%22A-higher-ranked%22%20label%3A%22A-closures%22 https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3A...
openuntil3am 8mo ago
Closures are a complicated mess. Functional programming languages hide the mess with garbage collection.
- andrewflnr 8mo ago
  This isn't the right framing IMO. Closures actually aren't complicated with GC for the same reason structs with references aren't complicated, at least as far as the programmer is concerned. You could say functional languages "hide the mess" there too, but even if you take that perspective, it's nothing to do with closures in particular. Closures are just one of the things that need memory, and memory management is tricky without GC.
- armchairhacker 8mo ago
  Machine code and LLVM are complicated messes. Higher-level language hide a lot, but sometimes issues pop up, even in Rust e.g. inline heuristics (https://nnethercote.github.io/perf-book/inlining.html https://nnethercote.github.io/perf-book/inlining.html).
ordu 8mo ago
Well... Rust is not a functional language, so it is not surprising that its closures are complicated.
SkiFire13 8mo ago
Functional programming languages usually don't support linear/affine types, non-gc references and mutations. Their closures are essentially the equivalent of Rust's `Rc<dyn Fn(...) -> ...>` with some sugar for expressing the function type and hiding all the `.clone()`s needed. It's easy to get simplier results if you support less features and use cases.

andy_xor_andrew 8mo ago

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)

KolmogorovComp 8mo ago
This is correct. But it’s not really surprising, it’s type inference.
- gpm 8mo 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.
  - chowells 8mo ago
    So you're saying... it's type inference of type classes, just like in Haskell?
    - csomar 8mo ago
      I am not sure how Haskell works but I think what the previous poster meant is that the types get determined at compile time. Closures are akin to macros except you can't see the expanded code.
    - gpm 8mo ago
      No, I don't think so, not unless there's some feature of Haskell type classes I'm completely unaware of. If anything it's closer to SFINAE in C++ where it tries to implement methods but then doesn't consider it an error if it fails. Then infers type-classes based on the outcome of the SFINAE process. Or the macro analogy another poster made isn't bad (with the caveat that it's a type system aware macro - which at least in rust is strange).

Sytten 8mo 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.

deleted 8mo ago

[deleted]

OptionOfT 8mo 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 8mo ago
This article discusses making captures more flexible: https://smallcultfollowing.com/babysteps/blog/2025/10/22/explicit-capture-clauses/ 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.

BlackFly 8mo 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.

wtetzner 8mo ago
Do you have an example of this? I'm not sure I follow it exactly.
tuetuopay 8mo 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 8mo 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); }
  - tuetuopay 8mo ago
    Ha, yes, I see what you mean now. That's not really the closure's fault but monomorphization of the foo function. The specific thing you want to do would require boxing the value, or do more involved typing.

stevefan1999 8mo 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 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.