This creates an empty iterator, like `repeat_n(value, 0)` but without
needing any such value at hand. There's precedent in many other
iterators that the `Default` is empty, like `slice::Iter`.
I found myself wanting this for rayon's `RepeatN` as it lowers to a
sequential iterator [here][1]. Since rayon is also optimizing to avoid
extra clones, it may end up with parallel splits that have count 0 and
no item value. Calling `std::iter::repeat_n(x, 0)` just drops that
value, but there's no way to construct the same result without a value
yet. This would be straightforward with an empty `Default`.
[1]: https://github.com/rayon-rs/rayon/blob/ae07384e3e0b238cea89f0c14891f351c65a5cee/src/iter/repeat.rs#L201-L202
Implement Step for NonZero unsigned integers as discussed in
[libs-team#130][1].
[1]: https://github.com/rust-lang/libs-team/issues/130
`step_nonzero_impls` was adapted from `step_integer_impls` and the tests
were adapted from the step tests.
Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
Don't fuse in `MapWindows`
cc https://github.com/rust-lang/rust/issues/87155
Fusing makes the iterator larger, slower, more complicated, and less useful. Users who need fusing behavior can always use `.fuse()`, but there is no way to get non-fusing behavior from the fused version.
@rustbot label A-iterators
Clarified doc comments + added tests confirming current behavior for intersperse/intersperse_with
This PR builds on top of rust-lang/rust#152855. I just added clarifying comments to `intersperse`/`intersperse_with` about its guarantees for fused iterators (and how behavior for non-fused iterators are subject to change). I also added in tests for non-fused iterators demonstrating its current behavior; fused iterators are already tested for in existing tests for `intersperse`/`intersperse_with`.
core: simplify `Extend` for tuples
This is an alternative to https://github.com/rust-lang/rust/pull/137400. The current macro is incredibly complicated and introduces subtle bugs like calling the `extend_one` of the individual collections in backwards order. This PR drastically simplifies the macro by removing recursion and moving the specialization out of the macro. It also fixes the ordering issue described above (I've stolen the test of the new behaviour from https://github.com/rust-lang/rust/pull/137400). Additionally, the 1-tuple is now special-cased to allow taking advantage of the well-optimized `Extend` implementations of the individual collection.
Some history: The Zip TrustedRandomAccess specialization has tried
to emulate the side-effects of the naive implementation for a long time,
including backwards iteration. 82292¹ tried to fix unsoundness (82291¹) in that
side-effect-preservation code, but this introduced some panic-safety
unsoundness (86443¹), but the fix 86452¹ didn't fix it for nested Zip
iterators (137255¹).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces
the number of cases in which side-effects will be preserved; the necessary
API guarantee change was approved in 83791¹ but we haven't made use of that
so far.
¹ see merge commit for linkfied issues.
Jonathan Brouwer