> `.map(...)` implies "I don't care about ordering, and therefore you don't need to, either"
In plenty of languages, no such implication exist. `map` can be specified to run in a certain order.
In plenty of languages, no such implication exist. `map` can be specified to run in a certain order.
But `FnMut` is the most general possible thing you can pass in. In reality, most callbacks are pure functions that don't alter mutable state at all. With Rust's monomorphization and aggressive inlining, LLVM can figure out that there's no mutation going on and can optimize that.
There is a wrinkle here, which is that capturing variables mutably is one of two ways a function can have side effects in Rust. The other way is via interior mutability, through UnsafeCell [1], or, more commonly, a wrapper around it like Mutex or RefCell. In that case as well, Rust guarantees that function calls to map are done in order. Luckily, because UnsafeCell is the root of all interior mutability, the compiler can simply track whether an UnsafeCell is transitively involved.
If you're wondering where the humble `print!` comes in -- well, it clearly has side effects. But it acquires a global lock on standard output each time it's called [2], so UnsafeCell is involved.
[1] https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html
C# and Javascript are the ones that I know of for sure.