Proposal: Lambda Patterns

[alrz]

Currently C# has a nice homoiconicity between expressions and delegates (aka expression trees). I want to suggest to bring that to patterns as well via lambdas.

Expression<Func<string, int>> expr = x => x.Length;

switch(expr) {
  case x => x.Length: break;
  case x => x.(string member): break;
}

// roughly translates to
switch(expr) {
  case LambdaExpression { Body is MemberExpression { Member is MemberInfo {
    Name is "Length" } } }: break;
  case LambdaExpression { Body is MemberExpression { Member is MemberInfo {
    Name is string member } } }: break;
}

Expression<Func<string, int>> expr = x => x.IndexOf("foo");

switch(expr) {
  case x => x.IndexOf("foo"): break;
  case x => x.IndexOf(string param): break;
}

// roughly translates to
switch(expr) {
  case LambdaExpression { Body is MethodCallExpression { Method is MethodInfo {
    Name is "IndexOf" }, Arguments is { ConstantExpression { Value is "foo" } } } }:
    break;
  case LambdaExpression { Body is MethodCallExpression { Method is MethodInfo {
    Name is "IndexOf" }, Arguments is { ConstantExpression { Value is string param } } } }:
    break;
}

• For Arguments I'm using list patterns, proposed in Proposal: List, Indexer (Dictionary) and String Patterns #5811.
• Type of the parameter x is inferred from the target expr.
• Pattern compatibility would be defined as matching lambda signatures and the target expression.
• All the additions in #2060 can be used in lambda patterns.
• The proposed translations are incomplete because the generated pattern should also check that the member comes form the first parameter i.e. Expression property must be a ParameterExpression.
• Parameter names are insignificant and they just matched by type and position.

[orthoxerox]

What would lamba patters be used for?

[alrz]

@orthoxerox Instead of any expression tree inspection that you currently need to write by hand or perhaps more verbosely with property patterns, as the final translation suggests.

[pawchen]

I like the idea, inspecting expression trees in API codes can be painful in both writing and reading. Maybe the title should be expression trees instead of lambda?

[alrz]

@DiryBoy Had the same thought. I don't mind the title but it seems a lambda that is a pattern, right? Because expression tree pattern could be confusing as the hypothetical translation suggests, you still can match expression tree types via property patterns.

[pawchen]

Right, so please forget about the title change:)

[svick]

What I don't like about this is that it introduces quite a heavy new syntax, but that syntax is useful only in pretty niche situations.

I think that pattern matching expression trees could work pretty well using some well-written is operators. Using the examples from above:

switch (expr.Body) {
  case Member(*, "Length"): break;
  case Member(*, string member): break;
}

switch (expr.Body) {
  case MethodCall(*, "IndexOf", { Constant("foo") }): break;
  case MethodCall(*, "IndexOf", { Constant(string param) }): break;
}