IEnumerable Tuple GetEnumerator

[Logerfo]

Background and Motivation

dotnet/csharplang#2197 (comment)

Proposed API

public static IEnumerator<(T1, T2)> GetEnumerator<T1, T2>(this (IEnumerable<T1> a, IEnumerable<T2> b) pair) => pair.a.Zip(pair.b, (a, b) => (a, b)).GetEnumerator();

For several arities, starting at two, it can go on:

public static IEnumerator<(T1, T2, T3, T4)> GetEnumerator<T1, T2, T3, T4>(this (IEnumerable<T1> a, IEnumerable<T2> b, IEnumerable<T3> c, IEnumerable<T4> d) pair)
 => pair.a.Zip(pair.b, (a, b) => (a, b)).Zip(pair.c, (a, c) => (a.a, a.b, c)).Zip(pair.d, (a, d) => (a.a, a.b, a.c, d)).GetEnumerator();

I don't know where this could go, because GetEnumerator as extension methods is a new thing.

Usage Examples

foreach(var (a, b) in (collectionA, collectionB)) 
{
	// This block will execute only while both `a` and `b` continue to yield values

	// Code goes here
}

Tagging subscribers to this area: @eiriktsarpalis, @jeffhandley
See info in area-owners.md if you want to be subscribed.

[stephentoub]

Why is this sufficiently better than:

foreach(var (a, b) in collectionA.Zip(collectionB))
{
}

to warrant a new API?

[Logerfo]

@stephentoub I think the bigger the arity, the bigger the gain from the feature:

public static IEnumerator<(T1, T2, T3, T4)> GetEnumerator<T1, T2, T3, T4>(this (IEnumerable<T1> a, IEnumerable<T2> b, IEnumerable<T3> c, IEnumerable<T4> d) pair)
 => pair.a.Zip(pair.b, (a, b) => (a, b)).Zip(pair.c, (a, c) => (a.a, a.b, c)).Zip(pair.d, (a, d) => (a.a, a.b, a.c, d)).GetEnumerator();


foreach(var (a, b, c, d) in (collectionA, collectionB, collectionC, collectionD)) 
{
	// This block will execute only while both `a`. `b`, `c` and `d` continue to yield values

	// Code goes here
}

So you can have var (a, b, c, d) in (collectionA, collectionB, collectionC, collectionD) instead of var (((a, b), c), d) in collectionA.Zip(collectionB).Zip(collectionC).Zip(collectionD).

[stephentoub]

I think the bigger the arity, the bigger the gain from the feature

Thanks. So the actual proposal is for a bunch of methods/overloads like the one you included in the initial post?

[Logerfo]

@stephentoub Yes, for several arities. I'll add that to the original post.

[stephentoub]

Thanks. Without agreeing or disagreeing with the feature, wouldn't it be better to expose it as additional Zip overloads that return IEnumerable? Then the output is consumable also by other IEnumerable-based APIs, e.g. the rest of LINQ. It also avoids the oddity of such IEnumerator-returning extension methods that would be a first for LINQ.

The overload:

public static IEnumerable<(TFirst First, TSecond Second)> Zip<TFirst, TSecond>(this IEnumerable<TFirst> first, IEnumerable<TSecond> second);

already exists, so I think you'd just be proposing some additional higher arities there, e.g.

public static IEnumerable<(TFirst First, TSecond Second, Third Third)> Zip<TFirst, TSecond, TThird>(this IEnumerable<TFirst> first, IEnumerable<TSecond> second, IEnumerable<Third> third);

[Logerfo]

@stephentoub Hmm, I see. That would be a step towards a better experience with foreaches, but in that case I think the original proposal is better. But I recognize that your proposal makes the data more viable for LINQ. What I'm thinking is that both proposals are not mutually exclusive. Both can be implemented and each one has its best use case. In fact, the implementation of the original proposal would be simpler if your proposal is already implemented, since it would be a simple proxy implementation.

[stephentoub]

What I'm thinking is that both proposals are not mutually exclusive

Personally I don't see a lot of benefit in adding additional methods to enable:

foreach (var (a, b, c) in (collectionA, collectionB, collectionC)) { ... }

instead of:

foreach (var (a, b, c) in collectionA.Zip(collectionB, collectionC)) { ... }

I actually think the former is problematic as, while terse (though saving only two characters), it's not intuitive to me what it means to enumerate a tuple. Why does that imply zip? Why not cross product, for example?

[Logerfo]

@stephentoub I see the zip operation as straightforward, but I cannot explain why. As I already consider your proposal as an improvement, I think we can move forward creating new overloads for arities greater than two for the extension method you pointed out.

[eiriktsarpalis]

Hi @Logerfo, sounds good to me, would you be able to update your original API proposal so that it reflects the change?

[Logerfo]

@eiriktsarpalis I'm closing this issue and opened another one at #43702. Thanks.