Argument Deconstruct

[lucasteles]

Being able to focus on just a part of a data structure can be very handy sometimes, would be nice to have a way to deconstruct arguments in a similar way we do in pattern matching.

This works today:

void Stuff(string bar, int baz) => Console.WriteLine($"{bar} and {baz}");

void PrintFoo(Foo foo) {
    var (bar, baz) = foo;
    Stuff(bar, baz);
}

void PrintFoo2(Foo foo) {
    if (foo is { Bar: var bar, Baz: var baz })
        Stuff(bar, baz);
}

record Foo(string Bar, int Baz);

This prosal:

void PrintFoo(Foo (bar, baz)) => Stuff(bar, baz);
void PrintFoo(Foo { Bar: var bar, Baz: var baz }) => Stuff(bar, baz);
void PrintFoo(Foo { Bar: var bar }) => Stuff(bar, 0);

// or even 
void PrintFoo2(Foo foo) {
    var { Bar: bar, Baz: baz } = foo;
    Stuff(bar, baz);
}

[CyrusNajmabadi]

What should happen if the pattern matching fails?

[lucasteles]

It should not fail, I don't think this has to be a pattern matching, would be better to be only a deconstruction of the defined argument type. So It must respect the type scheme to be able to deconstruct.

The only thing I see that could fail is to try to deconstruct a null property

[HaloFour]

See: #153
Also see: #3546

I want to say that we've also had a proposal or two about overloading via patterns, where the overload invoked depending on which pattern matches the arguments in lexicographical order. That kind of overloading is more commonly found in functional languages and is resolved at runtime whereas in C# overload resolution occurs at compile time.

This proposal appears to be infallible deconstruction via pattern matching, where the signature of the method must refer to the type of each formal parameter and where you can't have multiple methods where those types overlap but the patterns differ. Presumably the pattern would have to be infallible, which might limit their usefulness, although one could argue that a fallible pattern could also serve as an inline form of method contract.

void PrintFoo(Foo { Bar: var bar } foo) => Stuff(bar, 0);

// compiles to:
void PrintFoo(Foo foo) {
    var bar = foo.Bar;
    Stuff(bar, 0);
}

// fallible:
void PrintFoo(Foo { Bar: string bar } foo) => Stuff(bar, 0);

// compiles to:
void PrintFoo(Foo foo) {
    if (foo is { Bar: string bar }) {
        Stuff(bar, 0);
    }
    else {
        throw new ArgumentException(nameof(foo));
    }
}

[CyrusNajmabadi]

@HaloFour thanks. It's interesting, i'm just not sure if it's that much better than:

void PrintFoo(Foo foo)
    => foo is { Bar: string bar } ? Stuff(bar, 0) : throw new ArgumentException(nameof(foo));

But i don't feel very strongly one way or the other.

[lucasteles]

@CyrusNajmabadi I feel it is an overall great syntax sugar, it is a common feature in F# and JS.

I like the idea of having the fallible deconstruction, but my initial idea is to cover only the infallible cases at this moment

[orthoxerox]

This kind of fallible deconstruction could be a way to split a DU-handling method into a method per each case.

[HaloFour]

@orthoxerox

Blast from the past! dotnet/roslyn#15111

Also: dotnet/roslyn#6067

[Phantonia]

If patterns applied to parameters can be used for validation and deconstruction, maybe this could be a general validation mechanism which would also enable simple null checking.
Like this:

void X(string { } str) { }

Not that I like that syntax but at least it would be consistent with current if (str is { }) checks.

[lucasteles]

I like it, this could be a more idiomatic want to substitute the !! syntax

[lucasteles]

Mainly thinking in the infallible cases, this could be nice to lambdas too

Action<Foo> a = ((bar, baz)) => Stuff(bar, baz);
Action<Foo> a = ({ Bar: var bar, Baz: var baz }) => Stuff(bar, baz);
Action<Foo> a = ({ Bar: var bar }) => Stuff(bar, 0);