Expand .zip() specialization to .map() and .cloned() #37230
Conversation
Implement .zip() specialization for Map and Cloned. The crucial thing for transparent specialization is that we want to preserve the potential side effects. The simplest example is that in this code snippet: `(0..6).map(f).zip((0..4).map(g)).count()` `f` will be called five times, and `g` four times. The last time for `f` is when the other iterator is at its end, so this element is unused. This side effect can be preserved without disturbing code generation for simple uses of `.map()`. The `Zip::next_back()` case is even more complicated, unfortunately.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
I don't feel this is ready yet. @Stebalien, do you want to review it? Maybe there's a simpler way? Extending this to .map() is worth a bit of complexity, but it also casts doubt on if we can make TrustedRandomAccess into a publically available trait (?). If it gets too complex to use, I mean. The bulk of the complexity here is not in the implementations of that specialization trait though, but instead in The testcases should demonstrate why keeping track of the side effects is a bit ugly. One can't just specializal case .next() and let .next_back() be. I thought back to the "next_unchecked()" proposal but I don't think it helps -- it still needs to keep track of the length and number of elements taken the same way. |
| #[no_mangle] | ||
| pub fn zip_copy_mapped(xs: &[u8], ys: &mut [u8]) { | ||
| // CHECK: memcpy | ||
| for (x, y) in xs.iter().map(|&x| x).zip(ys) { |
There was a problem hiding this comment.
Before this PR, this loop copies one byte at a time. So it's a nice improvement.
|
@bors: r+ Nice wins! |
|
📌 Commit ed50159 has been approved by |
…=alexcrichton Expand .zip() specialization to .map() and .cloned() Implement .zip() specialization for Map and Cloned. The crucial thing for transparent specialization is that we want to preserve the potential side effects. The simplest example is that in this code snippet: `(0..6).map(f).zip((0..4).map(g)).count()` `f` will be called five times, and `g` four times. The last time for `f` is when the other iterator is at its end, so this element is unused. This side effect can be preserved without disturbing code generation for simple uses of `.map()`. The `Zip::next_back()` case is even more complicated, unfortunately.
…=alexcrichton Expand .zip() specialization to .map() and .cloned() Implement .zip() specialization for Map and Cloned. The crucial thing for transparent specialization is that we want to preserve the potential side effects. The simplest example is that in this code snippet: `(0..6).map(f).zip((0..4).map(g)).count()` `f` will be called five times, and `g` four times. The last time for `f` is when the other iterator is at its end, so this element is unused. This side effect can be preserved without disturbing code generation for simple uses of `.map()`. The `Zip::next_back()` case is even more complicated, unfortunately.
bluss
added
the
relnotes
Implement .zip() specialization for Map and Cloned.
The crucial thing for transparent specialization is that we want to
preserve the potential side effects.
The simplest example is that in this code snippet:
(0..6).map(f).zip((0..4).map(g)).count()fwill be called five times, andgfour times. The last time forfis when the other iterator is at its end, so this element is unused.
This side effect can be preserved without disturbing code generation for
simple uses of
.map().The
Zip::next_back()case is even more complicated, unfortunately.