[Pre-RFC] Replace IteratorExt::zip with tuple iteration

[oli-obk]

How would it be impossible for (i32, i32, i32)? In general, I concur, but it’s incorrect to say it’s impossible, period.

correction: it is impossible to check with generics, and we already have [i32, 3] for that.

No, it doesn’t. The elements of the sequence (a, b, c) are a, b, and c, not (the elements of a, the elements of b, and the elements of c) all concatenated.

I think i found our disagreement. It’s not a disagreement but a misunderstanding: I don’t want to iterate over a, then b, then c. I want to iterate over all of them simultaneously like zip does.

so the first iteration yields a tuple of the first elements of a, b and c. The second iteration yields a tuple of the second elements of a, b and c. … and so on, until either a or b or c stop returning elements.

[DanielKeep]

I think i found our disagreement. It’s not a disagreement but a misunderstanding:

You’re correct in that I completely brain-farted on “zip”.

However, I still believe this is bad for exactly the same reasons. So it’s still a disagreement.

[Gankro]

tuple-iteration would be cool, but surely it’s a discovery hazard (like a lot of other cool ideas)?

[oli-obk]

what’s a discovery hazard?

[tbu]

what’s a discovery hazard?

That it’s hard to discover that tupling zips the iterators if you search for a way of zipping iterators.

[oli-obk]

true… although I’d assume stack-overflow solves this after the question has been asked a few times

[naicode]

I thing a possible solution would be to extend the iterator returned by zip with a additional method witch is like zip but includes the new item into the retuned tuples e.g.:

 for (x,y,z) in (1..10).zip(2..11).and(3..12) {
     //...
 }

(and is just a example name) note that I an not sure how feasible it is to implement this due to the need of generically Generating tuples preferable without macros. Neverless it should be possible.

Note that a (1..10, 2..11, 3..12) is not possible because it is a touple of iterators and iterating over a touple would (if it would be possible) lead to yielding each value respectivly, what might be possible is something like

 for (x,y,z) in (1..10, 2..11, 3..12).into_combined_iterator() {
    //...
 }

(You might have a shorter name)

Also note that changing the zip method on a iterator created by ziping to behave different Would be unsound. E.g if someone might have some iterator over tuples and then zip it the result should be independent whether or not the first iterator was created by e.g. iter. over a Vec of tuples or by zipping 2 iterators.

[oli-obk]

chaining won’t work without variadic generics or some very evil macro magic that doesn’t implement and for the “longest” tuple.

Note that a (1..10, 2..11, 3..12) is not possible because it is a touple of iterators and iterating over a touple would (if it would be possible)

oh it’s quite possible, i implemented it already, it’s just a question of backwards compatibility and convention (whether we want it or not).

Also note that changing the zip method on a iterator created by ziping to behave different Would be unsound. E.g if someone might have some iterator over tuples and then zip it the result should be independent whether or not the first iterator was created by e.g. iter. over a Vec of tuples or by zipping 2 iterators.

yea that would be madness

[netvl]

This is a very nice suggestion. Scala already does this, but only for tuples of size 2 and 3:

val x = Vector(1, 2, 3, 4)
val y = List(5, 6, 7, 8)
(x, y).zipped.map((x, y) => (x + y)/2).reduce(_ + _)

However, I do like that a decorator method should be called on a tuple in order to obtain something iterable better than just using tuples as an iterator.

[netvl]

Oh, I see that @naicode already has suggested this, nice!

[Gankro]

One can simply provide IntoIterator<(a, b)> for (A, B) where A: IntoIterator<a>, B: IntoIterator<b>

[nikomatsakis]

I’ve often thought that foo.zip(bar) doesn’t read as nicely as I would like, so I kind of like this idea, or some variant thereof. Discoverability is definitely an objection, though we play similar games for collect() and I’m pretty happy with the result. Definitely iterators are a tool one has to learn to write idiomatic Rust.

I have to think about japaric’s concern about backwards compat, but it doesn’t worry me overly much. For one thing, i’d probably be happy just supporting a small number of arities (say 2-12, as usual). You can always build up arbitrary arity by using nested 2-tuples after all. If we do add variadic generics, then we could still use them to add support for arities from 13+ in the future. It’d be a bit uneven but meh.

[glaebhoerl]

for (x, y, z) in (1…10, 2…11, 3…13)

Probably my Haskell showing, but my first instinct was to interpret this as a cartesian product ((1,2,3), (1,2,4), (1,2,5) … (1,2,13), (1,3,3), (1,3,4), … etc.) rather than a zip.

[oli-obk]

rfc on github: https://github.com/rust-lang/rfcs/pull/870

[bluss]

I prefer the explicit versions like (a, b, c).zip() or Zip::new((a, b, c)) too.

[lfairy]

Probably my Haskell showing, but my first instinct was to interpret this as a cartesian product ((1,2,3), (1,2,4), (1,2,5) … (1,2,13), (1,3,3), (1,3,4), … etc.) rather than a zip.

Yeah, there are at least four ways to interpret (a, b, c).into_iter():

1. Zip the iterators (original proposal)
2. Chain the iterators
3. Cartesian product (@glaebhoerl, Haskell)
4. Treat the tuple as a slice (@DanielKeep, Python)

Without context, it won’t be obvious which of these is being used.

[oli-obk]

tuple as slice won’t make sense if the type of the tuple elements differs, and would then make sense for all types (even those that don’t implement Iterator.

I now agree that there should be a TupleIterExt that offers .zip() and .prod() for all tuples of types implementing Iterator.

.chain() is special, as it can only exist if the iterators have the same Item type.

[hauleth]

but to have it possible in sane way we need variadic templates.

[oli-obk]

since this has been delegated to post-1.0 we can wait for variadic generics

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.