-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Reword the caveats on array::map
#126100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Reword the caveats on array::map
#126100
Conversation
Thanks to 107634 and some improvements in LLVM (particularly `dead_on_unwind`), the method actually optimizes reasonably well now. So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and encouraging `Iterator::map` where an array wasn't actually ever needed.
/// That means that `arr.map(f).map(g)` is, in general, *not* equivalent to | ||
/// `array.map(|x| g(f(x)))`, as the former calls `f` 4 times then `g` 4 times, | ||
/// whereas the latter interleaves the calls (`fgfgfgfg`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't be talking about iterator evaluation order. E.g. next_chunk
impls may evaluate like array.map and so any iterator method that uses chunking internally might also use that order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wasn't meant to reject the update to map
. I just meant that we shouldn't be referring to Iterator
order since the latter depends on the implementation. No such concern applies to the array method since it's evaluated eagerly and there's no possibility of specializing that.
Thanks to #107634 and some improvements in LLVM (particularly
dead_on_unwind
), the method actually optimizes reasonably well now.So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and keep encouraging
Iterator::map
where an array wasn't actually ever needed.