[API Proposal]: Linq Join return tuple similar to Zip

[Thaina]

Background and motivation

For simplicity of Join it should just return (TOuter,TInner) instead of the need for resultSelector

API Proposal

    public static IEnumerable<(TOuter,TInner)> Join<TOuter, TInner, TKey>(
        this IEnumerable<TOuter> outer,
        IEnumerable<TInner> inner, Func<TOuter, TKey> outerKeySelector,
        Func<TInner, TKey> innerKeySelector);

    public static IEnumerable<(TOuter,TInner?)> LeftJoin<TOuter, TInner, TKey>(
        this IEnumerable<TOuter> outer,
        IEnumerable<TInner> inner, Func<TOuter, TKey> outerKeySelector,
        Func<TInner, TKey> innerKeySelector);

    public static IEnumerable<(TOuter?,TInner)> RightJoin<TOuter, TInner, TKey>(
        this IEnumerable<TOuter> outer, IEnumerable<TInner> inner,
        Func<TOuter, TKey> outerKeySelector,
        Func<TInner, TKey> innerKeySelector);

API Usage

var keys = new[] { "x" ,"y" ,"z" };
var dict = new Dictionary<int,string>();

foreach (var (s,pair) in keys.Join(dict,(key) => key,(pair) => pair.Value))
    Console.WriteLine(s + " : " pair.Key);

Alternative Designs

Without this it need to make another lambda just for return tuple

foreach (var (s,pair) in keys.Join(dict,(key) => key,(pair) => pair.Value,(outer,inner) => (outer,inner)))
    Console.WriteLine(s + " : " pair.Key);

Also since the key might be calculated maybe the return should include key too?

public static partial class Enumerable
{
    public static IEnumerable<(TKey,TOuter,TInner)> Join<TOuter, TInner, TKey>(this IEnumerable<TOuter> outer, IEnumerable<TInner> inner, Func<TOuter, TKey> outerKeySelector, Func<TInner, TKey> innerKeySelector);
}

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-linq
See info in area-owners.md if you want to be subscribed.

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• Proposal: add Join overload that returns a valueTuple #28747
• Linq.Join with key as parameter #28733

[eiriktsarpalis]

Adding an overload that doesn't require a resultSelector seems doable, although I'm not sure what our design guidance is for methods in the same group having different return types.

Shouldn't this also be returning the key, aka IEnumerable<(TKey, TOuter,TInner)>?

cc @bartonjs @roji

[timcassell]

It should not return the TKey, the existing resultSelector only passes TOuter and TInner. If you were to return the key, it would have to return TKey innerKey and TKey outerKey, and it's not really useful since you can just get the keys again from the TOuter and TInner items.

[roji]

I'm not sure what our design guidance is for methods in the same group having different return types.

FWIW I'm also not sure we have public APIs returning tuples, though I agree that the proposed Join overloads would be useful; tons of code out there projects to an anonymous type via the result selector: x.Join(y, x => x.Id, y => y.Id, (x, y) => new { X = x, Y = y }); these usages would be simplified, with the added bonus of the returned tuple being deconstructible.

[timcassell]

There is precedent with the Zip extension. The original used a resultSelector, then overloads were later added that return tuple.

[roji]

There is precedent with the Zip extension. The original used a resultSelector, then overloads were later added that return tuple.

Good point. Yeah, Join is conceptually very similar to Zip - both correlate items from two streams and return those items (or a projection thereof), the difference is in the correlation method (Join is key-based, Zip is position-based).

So I'd say this indeed makes sense and would make a nice quality-of-life improvement.