Discussion: tuple splatting

[alrz]

Method arguments:

var tuple = (1, 2);
dictionary.Add(tuple..);
// ->
dictionary.Add(tuple.item1, tuple.Item2);

params parameters (we simply expand tuple elements to argument list, so this is not a special case):

Task.WhenAll(tuple..);
// ->
Task.WhenAll(tuple.Item1, tuple.Item2);

Collection initializers:

var arr = new[] { 1, tuple.. };
// ->
var arr = new[] { 1, tuple.Item1, tuple.Item2 };

Member access (binds to the member with the same name of each element, regardless of type):

var tuple = tupleOfTasks..Result;
// ->
var tuple = (tupleOfTasks.Item1.Result, tupleOfTasks.Item2.Result);

Tuple elements (names will be reserved):

var t = (1, tuple..);
// ->
var t = (1, name1: tuple.name1, name2: tuple.name2);

Open question: should we turn element names to argument names? (probably not)

var tuple = (value: 1, key: 2);
dicitonary.Add(tuple..);
// ->
dictionary.Add(value: tuple.value, key: tuple.key);

Array of a common type (probably not):

Task[] tasks = tupleOfTasks..;
// ->
Task[] tasks = new Task[]{tupleOfTasks.Item1, tupleOfTasks.Item2};

Open question: should we allow splatting to anonymous types? (probably not because tuple names are optional)

var t = new { tuple.. };
// ->
var t = new { tuple.name1, tuple.name2 }; 

[orthoxerox]

Open question: should we turn element names to argument names?

That's too much magic, IMO. I'd make it a warning if there's a tuple/parameter name mismatch.

params parameters:

No. Arrays are homogeneous, tuples are heterogeneous. Those that aren't are a special case, not a rule.

Array of a common type:

Double no. Why not use an extension method for that if homogeneous tuples are really common in the codebase?

Member access (binds to the member with the same name of each element, regardless of type):

Structural typing, but only for tuples? Why not special case it for things where we have language constructs that presume the existence of certain members (LINQ, using, await)?

Tuple elements (names will be reserved):

Maybe, but why not use a special operator for cases like this? One will be "splat", the other one "name-splat". Then it can also be used when splatting tuples into argument lists.

[alrz]

That's too much magic, IMO. I'd make it a warning if there's a tuple/parameter name mismatch.

Agreed. but making it a warning might be annoying if the tuple comes from an override parameter.

No. Arrays are homogeneous, tuples are heterogeneous. Those that aren't are a special case, not a rule.

If we simply expand tuple items to the argument list that would be automatically supported.

Why not use an extension method for that if homogeneous tuples are really common in the codebase?

Because you will need an extension method per each tuple length.

Structural typing, but only for tuples?

I think it doesn't mean "structural typing" exactly, the point is to select a member from all elements, like what Select does, but since tuples have different types we can't use an extension method.

Maybe, but why not use a special operator for cases like this?

I'd rather keep this simple as possible and I would gladly exclude every case that seems too magical, like the first one above.

[orthoxerox]

Is tuple projection really that common that we need special syntax that is more convenient than .Select(x => x.Property)?

I'd rather lobby broadcasting from Julia.

[alrz]

@orthoxerox Unless we have structural typing, it's not clear what is the type of x in your example, and even then, you should be able to "infer member constraints" which is another proposal on top of shapes.

[orthoxerox]

@alrz I'm not proposing to reuse the syntax. What I tried to say was that enumerable projection is surely much more common than tuple projection, and we have to use .Select(x => x.Property) to do it. Inventing new concise syntax for tuple projection seems therefore counterproductive to me. (tupleOfTasks.Item1.Result, tupleOfTasks.Item2.Result) is good enough.

[alrz]

(tupleOfTasks.Item1.Result, tupleOfTasks.Item2.Result) is good enough

I think the whole point of the discussion is to avoid that kind of code. 😄

[orthoxerox]

I still feel that tuples are the wrong tool for the job here. If there are multiple tasks, why put them in a tuple? Just to save on array allocation?

[alrz]

@orthoxerox

Not if the Result is not of a same type for each task. I will add some context to examples above.

[orthoxerox]

@alrz Then I'd rather wait for shapes.

[alrz]

@orthoxerox I wonder how would that look like from what I've seen in #164. Can you give an example?

[orthoxerox]

@alrz You were right to doubt me, this will require HKT support:

public shape SAwaitable<T>
{
    public T Result {get;}
    public TAwaiter<T> GetAwaiter() where TAwaiter<T> : SAwaiter<T>;
    ...
}

//witnesses omitted

public static (R1, R2, R3) Result<T1<R1>, T2<R2>, T3<R3>>(
    this (T1<R1>, T2<R2>, T3<R3>) tuple)
    where T1<R1> : SAwaitable<R1>
    where T2<R2> : SAwaitable<R2>
    where T3<R3> : SAwaitable<R3>
{
    return (tuple.Item1.Result, tuple.Item2.Result, tuple.Item3.Result);
}

[huoyaoyuan]

For the dictionary scenario, I think add an implicit convert from tuple to KeyValuePair could help harmlessly.

[mattwar]

Splatting is great for passing returned tuples to methods that don't consume tuples, all within an expression context. This makes sense if your primary use of tuples is for multiple return values. Having to always drop out to a statement context to deconstruct the tuple is annoying.

(int x, int y) GetPosition() { ... }
void MoveTo(int x, int y) { ... }

With splatting

MoveTo(GetPosition());

Without splatting

var p = GetPosition();
MoveTo(p.x, p.y);

or

var (x, y) = GetPosition();
MoveTo(x,y);

[alrz]

My argument is that it should be explicit to be applicable to other constructs like collection/array initializers. It being implict can be ambigious or confusing in some cases.

[asdfgasdfsafgsdfa]

I love the idea, but I don't like the suggested syntax with the two dots.

[Richiban]

Does splatting really require extra syntax? I know it's going to complicate overload resolution slightly, by not simply allow:

public void Foo(int x, int y)
{
	Console.WriteLine($"x: {x}, y: {y}");
}

var args = (4, 5);

Foo(args);

If there was, indeed, another method with the following signature:

public void Foo((int x, int y) t)
{
	// ...
}

Then that would obviously be a better overload match.

FYI, this is exactly what F# does so there's precedent.

[binki]

Member access (binds to the member with the same name of each element, regardless of type):

var tuple = tupleOfTasks..Result;
// ->
var tuple = (tupleOfTasks.Item1.Result, tupleOfTasks.Item2.Result);

Could this be extended to allow a method to accept tuples of arbitrary width and return the projection? I want to be able to write one method which implements this pattern so that I don’t need to do this all over:

await Task.WhenAll(new Task[] { tupleOfTasks.., });
var tupleOfResults = tupleOfTasks..Result;

to be something more like:

var tupleOfResults = await ResolveTupleAsync(tupleOfTasks);

The current splatting syntax doesn’t seem to encourage reusable code unless if there is somehow a way to make a method accept arbitrary tuple lengths and return likewise. If I were to implement ResolveTupleAsync I’d have to make <T1, T2>, <T1, T2, T3>, … and each body of the method, with splatting, would look identical. A change to one would require me to manually update all method bodies.

[Igorbek]

JavaScript uses ... as a spread operator syntax. I find it more agronomic also for C# tuples:

var tuple = (a: 1, b: 2);
dictionary.Add(...tuple); // dictionary.Add(tuple.a, tuple.b);

[springy76]

@Igorbek I think it is called "spread" operator

[Igorbek]

@Igorbek I think it is called "spread" operator

of course! sorry typo. fixed

[Thaina]

Is this predated by #1654 ?

[yaakov-h]

They are similar and related, but not the same.

Also, this issue predates #1654 by over a year.

[Thaina]

@yaakov-h Yeah, I think I misuse the word predate. I meant that this issue was made outdated by 1654

[yaakov-h]

@Thaina superceded?

If so, no. This issue discussed explicitly splatting tuples. The other one discuses having the compiler magically splat tuples implicitly.

[jfheins]

I would love that feature :-)

When I use tuples and extract methods, they often end up with many braces and unnecessary names in the definition.
It would be very nice to just use M2 like this:

public static class Program
{
    public static void Main()
    {
        var myTuple = (1, "example");
        M2(..myTuple); // lowered to M2(myTuple.Item1, myTuple.Item2)
    }

    static string M1((int length, string name) tuple) => tuple.length + tuple.name;
    static string M2(int length, string name) => length + name;
}