Discussion: Auto-splatting

[HaloFour]

C# method overloading is complicated. Probably too complicated. Obviously the best thing that we could do is complicate it some more!

I've been thinking about this a little since the discussion/debate/flame-war regarding "unit", that it would be neat if the lines between tuples and parameter lists could be blurred. Then when this proposal was published I began to wonder if it could apply to deconstructables in general.

So, to keep it short, what if the language could automatically consider a tuple/deconstructable value as arguments towards a method. Obviously this could only be considered if the tuple/deconstructable type wasn't already a valid argument.

Consider this 🍝 against the wall:

Splatting 101:

(int, string) A() => (123, "Hello World");
void B(int i, string s) { };

B(A());
// translated to:
var (temp1, temp2) = A();
B(temp1, temp2);

// given
public struct Point {
    public int X;
    public int Y;

    public Point(int x, int y) => (X, Y) = (x, y);

    public void Deconstruct(out int x, out int y) {
        x = X;
        y = Y;
    }
}

void A(int x, int y) { }
var point = new Point(4, 5);
A(point);

// translated to
var (temp1, temp2) = point;
A(temp1, temp2);

Mixing with arguments?

(int, string) A() => (123, "Hello World");
void B(int i, string s, long l) { }

B(A(), 123L);
// translated to
var (temp1, temp2) = A();
B(temp1, temp2, 123L);

Flattening?

(int, (string, long)) A() => (123, ("Hello World", 123L));
void B(int i, string s, long l) { }

B(A());
// translated to
var (temp1, temp2) = A();
var (temp3, temp4) = temp2;
B(temp1, temp3, temp4);

Tear it apart.

[rikimaru0345]

I love it!
I was so hyped when tuples were released thinking that what you wrote there was part of it (and then disappointed when it was not :P)

[scalablecory]

I think I'd be more comfortable if we could make it explicit with a ... operator similar to how C++ does variadic template expansion:

(int, string) A() => (123, "Hello World");
void B(int i, string s) { };

B(A()...);

That said, I feel like this feature very quickly makes code difficult to read (especially with mixing arguments or expanding multiple tuples) and so am not sure if it'd be worth adding to the language.

[james-uffindell-granta]

I'm with @scalablecory on this; doing it implicitly makes me nervous and I'd prefer an explicit operator to say "splat this Deconstructible here".

I was going to suggest prefix * (similar to splat operators in Python and Ruby), but that would clash with the unary * operator for pointers in unsafe contexts so might not be acceptable.

[MgSam]

You could easily construct situations where this will lead to ambiguity (if not for the compiler, then at least for the developer reading the code). I think adding auto-magical behavior requires an even higher bar than normal.

I do think adding a splat operator makes the feature a lot more palatable. But I'm still not convinced this is common enough for the benefit to be worth the cost.

[AustinBryan]

The first A(B()) should be B(A()), right?

Besides that, this seems a very natural extension of tuples, given how C# syntax for them mirrors parameter syntax (which was on purpose).

Great idea!

[DavidArno]

I'm seriously torn on this. A year ago, I'd have loved this: "yes, yes, yes, we must have this". Now though, I'm not so sure why I wanted it back then. It just feels too "clever", ie it sounds great in theory, but it's really hard in practice to understand what's going on. What's really odd to me is that I'm sure I was a big fan of this a year ago and you hated it then, but now the roles have reversed 😕

I especially struggle with the deconstruct idea. If I see foo(bar), I now have to understand what type bar is and know whether it has any deconstructs in order to work out which overload of foo is being used. I don't much like method overloading, but folk use it and I have to use it in turn as a result and this just seems to make that much harder.

I really want to like this though. And I have a nagging feeling that straight after posting this, I find a situation where I'll think "if only I could do splatting"...

[VisualMelon]

It's just too structural for me: positional parameters are iffy enough without hoping that 2 sets of them line up. If something operates on a Point (to use the example from the OP), it should take a Point. If it doesn't, then I'd want to explicitly decompose any points I want processed (perhaps writing an extension method to frame it nicely, and otherwise document the decision that it makes sense). I certainly don't want to be allowed to pass a point off without acknowledging that it's being deconstructed: I'd be less apprehensive if there was an explicit splatting operator as others have already suggested.

[HaloFour]

@AustinBryan

The first A(B()) should be B(A()), right?

Good catch! I've updated the post.

[HaloFour]

I kind of agree with much of the criticism here. There's a bit too much magic going on here that having an explicit "splat" operator might help clear up, but even then it's pretty complicated. If it applied to just tuples that might be more palatable as the number of situations where it could be ambiguous should be significantly reduced, but even then it might be difficult to ascertain what method is actually being called when dealing with overloads. At the end of the day it's probably not worth it, but it's fun to explore.

[bbarry]

Splatting was suggested in the original Roslyn issue about tuples: dotnet/roslyn#347

I do think it would be better if it was explicit and that would also avoid ambiguities.

[iam3yal]

A splat operator may also help with more cases like arrays, tuples that aren't necessarily returned from a function so it can be expanded to more areas.

Here are more cases where you might want to transform a tuple into an array and vice-versa.

var a = new int[] { ...t }
var at = ( ...a )

So in my opinion if we want to add something like a splat operator to the language it should go beyond unpacking tuples into argument list.

[Richiban]

I like this feature; ever since I learned F# and realised that

object.M (4, 5)

and

let args = 4, 5

object.M args

are (at a high level) the same thing; it actually kinda blew my mind. Given the fact that, in F#, all functions have the same signature: 'a -> 'b (equivalent of Func<T, R>), it just has a beautiful symmetry about it.

In C#, however, I think this would feel inconsistent and incomplete unless we were also able to treat say Func<T, U, R> and Func<(T, U), R> interchangeably:

public class ActionContainer<T>
{
	private readonly Action<T> _action;

	public ActionContainer(action) => _action = action;

	public void Execute(T arguments)
	{
		_action(arguments);
	}
}

var container = new ActionContainer<(string, object[])>(Console.WriteLine);

container.Execute("Arg1 {0}, arg2 {1}", new [] { "one", "two" });

In essence, I don't think that Tuple splatting on its own is very useful.

[Korporal]

So, is it being proposed that we introduce support for this:

    class Program
    {
        static void Main(string[] args)
        {
            var arguments = (123, "Hello", DateTime.Now);

            DoSomeWork(arguments);
        }

        static void DoSomeWork(int A, string B, DateTime C)
        {
            return;
        }
    }

[NN---]

Nemerle has this feature with implicitly expanding tuple.
It turns out that this does not play well with overloading and especially hit in LINQ.