Proposal: Pattern matching and record types

[gafter]

The spec has been moved

The specs for pattern matching and records have been moved to https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md and https://github.com/dotnet/roslyn/blob/features/records/docs/features/records.md

There are new discussion threads at #10153 for pattern-matching and #10154 for records.

[ghord]

Overall, great proposal.
Just a minor nitpcik: * seems a little out of place in language. I propose to simply use var instead by omitting variable name:

case Mult(var, Const(0)): return Const(0);
case Mult(Const(1), var x): return Simplify(x);

If we would allow to match by only type name and skip variable name, one could even perform simple type test cases like this:

bool IsInteger(Expr e) 
{
    switch(e) 
    {

        case Const(int): return true;
        case Const(double val): return IsInteger(val);
        case Const(var): return false;
        ...
    }
}

I think it would be more consistent behaviour.

[ztone]

F# record (for reference)

type Cartesian = { X : double; Y : double }
let c = { X = 1.0; Y = 2.0 }

This is similar valid C# syntax

class Cartesian { public double X; public double Y; }
var c = new Cartesian { X = 1.0, Y = 2.0 };

Proposal. This is a example of a simple syntax transition to a c# record from the code above. The record is an immutable class with just default public readonly fields. Records could use the expected immutable class implementation.

record Cartesian { double X; double Y; }
var c = new Cartesian { X = 1.0, Y = 2.0 };

var ok = c.X; // ok
c.X = 3.0; // Error, a readonly field cannot be assigned to.

Another option could be (although I would prefer the above)

record Cartesian { double X; double Y; }
var c = new Cartesian(X: 1.0, Y: 2.0);

var ok = c.X; // ok
c.X = 3.0; // Error, a readonly field cannot be assigned to.

Just my 2 cents

[casperOne]

Why would IEquatable<T> not be implemented? You're overriding Equals(object) already, so IEquatable<T> should be a no-brainer.

[SolalPirelli]

I may be reading the spec wrong, but it doesn't look like it's specifying the return type of operator is. Shouldn't it force it to be bool? The == and != operators lack such a constraint, but IMHO there is no valid use for non-bool-returning equality operators.

[mpawelski]

Were you considering to use _ character instead of * for wildcard pattern? Every language I can think of use this character for that.
I sometimes use this character as lambda argument to indicate that this parameter won't be used. I know that _ is a valid name for variables and classes and you can write something like this (_, other) => _.PropertyAccess but maybe there is a way to use this character and don't break existing code? For example previous code would compile (maybe with warning) and this one would fail (_, _) => _.PropertyAccess because _ would be treated as a wilcard character.

And when it comes to pattern matching we could disallow to name variable as _ (for examle this pattern Cartesian(var x, var _) won't compile) and allow _ to be wilcard character. It's a new feature so old code won't be broken.

I just thing that _ is so prevalent in other languages that it is worth considering to use it instead of *. For someone familiar with pattern matching from other language it would be instantaneously clear what the code do when they'll see C# code with pattern matching and with this character. I think similarity with other languages is nice to have.

[MgSam]

Great to see the updated proposal!

Some comments:

• The example shows auto-implementing of ToString, but the spec says only that Equals and GetHashCode will be implemented.
• I think auto-implementing of the == and != operators is a no-brainer here. IEquatable I don't feel strongly about as I never see types that actually use it.
• I like the record keyword. It seems weird that the mere existence of a primary constructor would initiate all this other magic behavior as well. Doing so may lead non-primary constructor classes to become second class citizens (as auto-implementation of GetHashCode, Equals, and ToString will do the right thing in 95% of cases and thus be highly desirable). IMO, the magic associated with records seems orthogonal to primary constructors.
• I really hope the design committee looks at the with operator. Immutability/records needs this operator to be useful without a ton of extra boilerplate for copying immutable types. As others have mentioned previously, Roslyn code would also benefit greatly from a with operator.
• The biggest value adds for the code I write every day are records (mostly as proposed) + with operator. The pattern matching stuff is just nice to have gravy.

[gafter]

These record types can easily support 'with' expressions like

Point p = ...;
p = p with { X: 4 };

which would generate

p = new Point(4, p.Y);

[gafter]

The == and != operators would only be a good idea for record structs. It is too easy to get in trouble with them on reference types.

[MrJul]

@MgSam IEquatable<T> is often used implicitly, for example in a Dictionary<TKey,TValue> or a HashSet<T> with the default comparer. EqualityComparer<T>.Default uses IEquatable<T> if it's available, or falls back to Object.Equals if it doesn't, meaning a perf/memory hit for value types due to boxing.