Add function core::iter::zip #82917

cuviper · 2021-03-08T23:33:33Z

This makes it a little easier to zip iterators:

for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}

You can zip(&mut xs, &ys) for the conventional iter_mut() and
iter(), respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary zip chains:

for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))

This replaces the tuple-pair IntoIterator in #78204.
There is prior art for the utility of this in itertools::zip.

rust-highfive · 2021-03-08T23:33:36Z

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

cuviper · 2021-03-08T23:33:59Z

r? @KodrAus

bluss · 2021-03-09T16:47:46Z

The main feature is that a free function can have a more permissive trait bound than a method - the method has to have a more specific receiver. The symmetry in the treatment of the two operands contributes to the readability of the code.

a.zip(b)
- a is an iterator and b is an iterable
- a is receiver and b is a parameter
zip(a, b)
- symmetry: a and b are iterable
- symmetry: a and b are function parameters
- (drawback) it's a binary function but it "should be" an n-ary operation with variadic generics

itertools has these "opinonated" free functions (that I introduced there), and the other one I'd speak for would be enumerate(iterable) with similar features to zip.

cuviper · 2021-03-09T16:57:04Z

the other one I'd speak for would be enumerate(iterable)

A particular thing I like about that one is that enumerate(iterable) matches the order (index, item), whereas iter.enumerate() reads backwards to me -- a method at the end which adds something to the front.

m-ou-se · 2021-03-27T09:56:29Z

Thanks for working on this, @cuviper!

Can you open a tracking issue? Thanks!

r=me with the tracking issue added.

cc @rust-lang/clippy: this makes minor changes to the clippy code in the last commit.

cuviper · 2021-03-27T17:17:08Z

Added tracking issue #83574.

@bors r=m-ou-se

bors · 2021-03-27T17:17:10Z

📌 Commit f0a6052 has been approved by m-ou-se

Rollup of 8 pull requests Successful merges: - rust-lang#81351 (combine: stop eagerly evaluating consts) - rust-lang#82525 (make unaligned_references future-incompat lint warn-by-default) - rust-lang#82626 (update array missing `IntoIterator` msg) - rust-lang#82917 (Add function core::iter::zip) - rust-lang#82993 (rustdoc: Use diagnostics for error when including sources) - rust-lang#83522 (Improve fs error open_from unix) - rust-lang#83548 (Always preserve `None`-delimited groups in a captured `TokenStream`) - rust-lang#83555 (Add #[inline] to io::Error methods) Failed merges: - rust-lang#83130 (escape_ascii take 2) r? `@ghost` `@rustbot` modify labels: rollup

Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x, y) in zip(xs, ys) {} // vs. for (x, y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and `iter()`, respectively. This can also support arbitrary nesting, where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x, y), z) in zip(zip(xs, ys), zs) {} for (x, (y, z)) in zip(xs, zip(ys, zs)) {} // vs. for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {} for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely, especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1), impl_trait_ref.substs.types().skip(1), ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in rust-lang#78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html

… r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (rust-lang#83574) for `iter::zip` completed the final commenting period without any concerns being raised, I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (rust-lang#82917) states, the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement, it has been integrated into the codebase without any trouble, and has been used in many places across the rust compiler and standard library since March without any issues. For more details, I would refer to `@cuviper's` original PR, or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).

The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ``` for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ``` There is prior art for the utility of this in `itertools::chain`.

The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ``` for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ```

…nieu Add function `core::iter::chain` The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ```rust for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ``` There is prior art for the utility of this in [`itertools::chain`](https://docs.rs/itertools/latest/itertools/fn.chain.html). Approved ACP rust-lang/libs-team#154

Rollup merge of rust-lang#106186 - rossmacarthur:ft/iter-chain, r=Amanieu Add function `core::iter::chain` The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ```rust for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ``` There is prior art for the utility of this in [`itertools::chain`](https://docs.rs/itertools/latest/itertools/fn.chain.html). Approved ACP rust-lang/libs-team#154

The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ``` for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ```

rust-highfive assigned petrochenkov Mar 8, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 8, 2021

rust-highfive assigned KodrAus and unassigned petrochenkov Mar 8, 2021