Discussion thread for pattern-matching

[gafter]

This is a discussion thread for pattern-matching, as specified in https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md

Please check the spec before adding your comment - it might have been addressed in the latest draft.

[orthoxerox]

Open questions:
Pattern matching with arrays.
Pattern matching with List, Dictionary

Every time I try to come up with a reasonably expressive syntax for this, any sample pattern explodes into a huge mess. On one hand, every extracted element must be assignable to an identifier, but on the other hand, we might want to apply a pattern to it which might not allow us to get one. I feel like restricting the pattern to extracting head(s) and a tail is a reasonable solution.

For example, what would "the token stream should contain a reserved word class, then an identifier" pattern look like? reservedWordClass::className::rest? This is missing all the checks, but adding them turns it into

ReservedWordToken{Keyword is "class"}::IdentifierToken className::rest

We're lucky that we can abandon the reserved word token and that identifiers are identified using inheritance and not a tag field. Otherwise this could look like

Token{Kind is Kind.Reserved, Keyword is "class"} :: Token{Kind is Kind.Identifier} identifier :: rest

At this point it still doesn't look too bad, but any further features turn the patterns into an undecipherable mess worse than programs by someone trying to use every single feature of scalaz, e.g. adding regular expression-like features or recursive matches.

The changes to the grammar look like this:

complex-pattern
    : type identifier
    | recursive-pattern
    | recursive-pattern identifier
    | property-pattern
    | property-pattern identifier
    | list-pattern
    ;

list-pattern
    : cons-pattern
    | empty-list-pattern
    ;

cons-pattern
    : car-pattern '::' cdr-pattern
    ;

car-pattern
    : complex-pattern
    | identifier
    ;

cdr-pattern
    : list-pattern
    | identifier
    ;

empty-list-pattern
    : '[]'
    ;

P.S. Does anyone else experience semantic satiation after reading the word 'pattern' thousands of times?

[HaloFour]

@orthoxerox I know that the "cons" operator :: is common among functional languages but I am quite concerned about opening the operator floodgates for the C# language.

I do think that "cons" patterns would apply well to C#, particularly for IEnumerable<T>, but I also like the idea of a collection-or-array initializer-like syntax, something like:

if (list is { ReservedWordToken{ Keyword is "class" }, IdentifierToken className }) { }
if (list is [ ReservedWordToken{ Keyword is "class" }, IdentifierToken className ]) { }

I like the former because it feels like a collection initializer, but I think it would preclude the option of having an implicitly typed property pattern. The latter smells like it has something to do with arrays and it is the list pattern in F# but it's not the initializer syntax.

As for the verbosity of any of these, I think that's just inherent with subpatterns, whether you're dealing with property patterns or list/array/cons/whatever patterns.

[Miista]

Every time I try to come up with a reasonably expressive syntax for this, any sample pattern explodes into a huge mess.

This is a lot how I feel when looking at the current spec.

In my opinion, it feels like the spec is trying too hard to do too much. It tries to deal with both how the object was constructed, what the object looks like internally, and conditionals.

is operator

The usage of is feels weird. The user-defined operator given in the spec would allow:

var c = Cartesian(3, 4);
if (c is Polar(var R, *)) Console.WriteLine(R);

However, the usage of is implies some sort of relationship between c, Cartesian, and Polar.
But Polar is not of type Cartesian nor is it an instance of Cartesian, and c is not of type Polar nor is it an instance of Polar.
Polar isn't even a subclass of Cartesian so this logically makes no sense.

What this tries to achieve has nothing to do with matching on the structure of c. What you really want to know here is whether the expression c.X != 0 || c.Y != 0 is true. So put that in a match expression (as below). This would also avoid the whole thing with user-defined is operator.

var c = Cartesian(3, 4);
c match {
    case Cartesian(var x, var y) when x != 0 || y != 0 => {
      var r = Math.Sqrt(x*x + y*y);
      Console.WriteLine(r);
    }
}

If Polar instead was a subclass of Cartesian that exposed R as a property it would make more sense to use the is operator but in that case the following would be a more clear way of achieving the same thing:

public class Polar : Cartesian
{
    public double R { get; }
    public double Theta { get; }

    public Polar(int x, int y) : base(x, y) { ... }
}

var c = Polar(3, 4);
if (c is Polar p)
{
    Console.WriteLine(p.R);
}

So to sum up; pattern matching with a user-defined is operator is just extremely confusing.

As for ReservedWordToken{Keyword is "class"}::IdentifierToken className::rest; again, the is operator is being abused. Now using is means to check for equality. What's next?!

[HaloFour]

I think allowing "property patterns" to omit the type name when the compiler already knows the type would be useful both in keeping the verbosity down as well as allowing the property pattern to work with anonymous types:

Rectangle rectangle = new Rectangle(100, 100);
var anonymous = new { Width = 100, Height = 100 };

if (rectangle is Rectangle { Width is 100, Height is var height }) { }
if (rectangle is { Width is 100, Height is var height }) { }
if (anonymous is { Width is 100, Height is var height }) { }

object obj = rectangle;
if (obj is Rectangle { Width is 100, Height is var height }) { }
if (obj is { Width is 100, Height is var height }) { } // compiler error

This syntax might also be able to apply to dynamic types. What I don't know is whether the compiler can emit code to attempt to bind to the properties to test for their existence:

dynamic dyn = rectangle;
if (dyn is { Width is 100, Height is var height }) {
    // succeeds if both the Width and Height properties exist
    // Width must also be successfully compared to the constant pattern 100
    // height is of type dynamic and could be any value
}

[Miista]

I do think that "cons" patterns would apply well to C#, particularly for IEnumerable, but I also like the idea of a collection-or-array initializer-like syntax, something like:

if (list is { ReservedWordToken{ Keyword is "class" }, IdentifierToken className }) { }
if (list is [ ReservedWordToken{ Keyword is "class" }, IdentifierToken className ]) { }

In that case I would much rather see people use a match/switch expression and put "Keyword is "class"" in the guard clause.

[alrz]

but I think it would preclude the option of having an implicitly typed property pattern

@HaloFour That couldn't be ambiguous. I'm assuming the syntax proposed in #5811 works,

list-subpattern:
 pattern

property-subpattern:
 identifier is pattern

o is { 1, 2 }
o is { P is 1 }

@orthoxerox I don't know why there is a need for "cons" operator, because IEnumerable<T> or List<T> are not linked lists unlike FSharpList<T>. I think you should probably use slice patterns (#120), e.g.

list is { int first, .. int[:] rest }

or something like that.

[HaloFour]

@alrz

If that's not considered ambiguous either visually or by the parser then it works for me. Would it be worth having different patterns for arrays, lists, enumerables, etc. or just have the compiler emit what it thinks would be best given what it knows about the type of the operand?

Also, 🍝:

// list must contain at least two elements
// remaining elements will be copied/sliced to rest, which can be empty
if (list is { 1, 2, params int[] rest }) { ... }

Perhaps that could be params IEnumerable<int> also.

[alrz]

@HaloFour What difference does it make? All you want is to match the target with this pattern, the type which the pattern will be matched against doesn't matter (to user) — analogous to array and collection initializers.

In your example, you should use int[:] as it is still a slice of the whole array (or any other collection types that slices would support). It would be equivalent to:

// matches an array that begins with values `1` and `2` with Length >= 2
if(arr is { 1, 2, *** }) { 
  int[:] rest = arr[2:]; // skips the first two items
}

It has nothing to do with parameters though. A syntax similar to this .. is used in ES6 I guess.