Proposal: deconstruction of formal parameters

[orthoxerox]

Depends on #39. Copied from dotnet/roslyn#15111.

Trivial record types are a common pattern in functional languages, providing additional type safety over bare numbers or strings or tuples:

//I'm using the not yet existing record syntax here
public struct EmailAddress(string emailAddress);
public struct Velocity(float velocity);
public struct PointD(double x, double y);

However, using them in C# requires additional deconstruction or constant member access:

public static Result SendEmail(
    EmailAddress to, 
    IEnumerable<EmailAddress> cc, 
    string subject, 
    string body)
{
    var to1 = EmailAddress.EmailAddress;
    //or alternatively...?
    to is EmailAddress(var to2);
    //or...?
    let EmailAddress(var to1) = to;
    
    var cc_ = cc.Select(x=>x.EmailAddress);
    //etc
}

I propose to allow positional deconstruction in method declarations.

public static PointD operator +(PointD(var x1, var y1) p1, PointD(var x2, var y2) p2)
    => new PointD(x1+x2, y1+y2);

Deconstructed parameters can lack their own names if they have only one parameter:

public static Velocity Scale(Velocity(var velocity), Factor(var factor))
    => new Velocity(velocity * factor);
    
//this is transformed into

public static Velocity Scale(Velocity velocity, Factor factor)
{
    var generatedname1 = velocity.Velocity;
    var generatedname2 = factor.Factor;
    return new Velocity(generatedname1 * generatedname2);
}

Deconstruction of types parameterized by deconstructible types, like cc in SendMail above, is an open question:

public static Result SendEmail(
    EmailAddress(var to), 
    IEnumerable<EmailAddress(var cc)>, 
    string subject, 
    string body)
{
    //cc must be an IEnumerable<string>
    //...
}

Perhaps it can be done rather straightforwardly for all monadic (LINQ-able) types.

[YaakovDavis]

@orthoxerox

Deconstructed parameters can lack their own names if they have only one parameter

Why restrict to records with one param only? The following looks doable as well:

public static PointD operator +(PointD(var x1, var y1), PointD(var x2, var y2))
    => new PointD(x1+x2, y1+y2);

[orthoxerox]

Because this will look terrible in Intellisense otherwise.

[YaakovDavis]

As a rule, Intellisense can show the deconstruction for nameless params.
i.e. for the following method,

void ProcessResult(Context(var env, var settings) context, Result(var value, var isSuccess))

the following signature will be shown in intellisene:

void ProcessResult(Context context, Result(var value, var isSuccess))

In some scenarios, the names in the deconstruction might be more meaningful than naming the record as a whole. With the above design, the API designer can hint the consumer how to construct the args.

[orthoxerox]

What if I want to consume this from a language that doesn't know anything about nameless parameters?

[YaakovDavis]

Many of the new C# features will look odd for consumers from other languages, including tuples, ADTs, and so on.
Not sure the language's design should be restricted based on such factors.

[gafter]

Generally speaking we prefer to keep implementation details such as this out of the "header" of a method.

[orthoxerox]

@gafter what about this.Member default values or base()/this(), even?

[gordanr]

I am very interested in trivial record types, but I find classical approach more readable.

public static PointD operator +(PointD p1, PointD p2)
    => new PointD(p1.x + p2.x, p1.y + p2.y);

[gafter]

@orthoxerox The this.Member default values are part of the contract. The base() or this() I consider to be following the method header.