Comment by yoshuaw
12 hours 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`.
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.
I'm not sure myself, does Fn correspond to reentrancy or is there some detail I am missing?
`Fn`, `FnMut`, and `FnOnce` can also implement and not implement `Sync` (also `Send`, `Clone`, `Copy`, lifetime bounds, and I think `use<...>` applies to `impl Fn...` return types).
EDIT: https://news.ycombinator.com/item?id=46750011 also mentioned `AsyncFn`, `AsyncFnMut`, and `AsyncFnOnce`.