Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Rust Closures

antoine.vandecreme.net

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Understanding Rust Closures

#11

Post by yoshuaw »

andy_xor_andrew wrote: post #4

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 g…

> 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`.

Re: Understanding Rust Closures

#12

Post by School-Cotton »

yoshuaw wrote: post #11
andy_xor_andrew wrote: post #4

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 g…

> 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 c…

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.

Re: Understanding Rust Closures

#13

Post by speed_spread »

convolvatron wrote: post #6
Klonoar wrote: post #3

Earlier quoted context omitted.

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.

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.

Async is the stuff that messes up everything. Closures are not complicated.

Re: Understanding Rust Closures

#14

Post by krukah »

andy_xor_andrew wrote: post #4

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 g…

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

FnOnce

FnMut

Fn

Re: Understanding Rust Closures

#15

Post by Sytten »

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.

Re: Understanding Rust Closures

#16

Post by gpm »

KolmogorovComp wrote: post #7
andy_xor_andrew wrote: post #4

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 g…

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

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.

Re: Understanding Rust Closures

#17

Post by bobbylarrybobby »

andy_xor_andrew wrote: post #4

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 g…

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).

Re: Understanding Rust Closures

#18

Post by [deleted] »

andy_xor_andrew wrote: post #4

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 g…

[deleted]
Post reply on HN