4 ms·

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

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

kstrauser 2y ago
Then that may not be an appropriate optimization for those languages.
- recursive 2y ago
  That's what I'm saying. In fact, I think that's most languages.
chabska 2y ago
What languages would that be?
- recursive 2y ago
  Probably most that has imperative stuff or closures. Here's the spec from ECMAscript. https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map https://tc39.es/ecma262/multipage/indexed-collections.html#s... C# and Javascript are the ones that I know of for sure.
dhosek 2y ago
The author is confusing .map(…) with the Map interface for collections.
sunshowers 2y ago
It's interesting -- so, logically, `map` in Rust does imply an ordering. The closure is a `FnMut`, i.e. a callback which mutably captures values, causing external side effects. And it is guaranteed that if externally visible, mutations will be done in 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 https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html [2] https://doc.rust-lang.org/std/macro.print.html https://doc.rust-lang.org/std/macro.print.html

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

kstrauser 2y ago

Then that may not be an appropriate optimization for those languages.

recursive 2y ago
That's what I'm saying. In fact, I think that's most languages.

chabska 2y ago

What languages would that be?

recursive 2y ago
Probably most that has imperative stuff or closures. Here's the spec from ECMAscript. https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map https://tc39.es/ecma262/multipage/indexed-collections.html#s... C# and Javascript are the ones that I know of for sure.

dhosek 2y ago

The author is confusing .map(…) with the Map interface for collections.

sunshowers 2y ago

It's interesting -- so, logically, `map` in Rust does imply an ordering. The closure is a `FnMut`, i.e. a callback which mutably captures values, causing external side effects. And it is guaranteed that if externally visible, mutations will be done in 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 https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html [2] https://doc.rust-lang.org/std/macro.print.html https://doc.rust-lang.org/std/macro.print.html