Promote "when" from pattern guard to guard pattern

[HaloFour]

Currently the when keyword is used only in switch statements/expressions to allow a boolean expression to be evaluated after a pattern has been matched:

switch (operand) {
    case pattern when expression:
        statements;
        break;
}

This was fine with simple patterns, but with support for more complicated recursive patterns this suffers from the problem that the condition that is to be evaluated can be somewhat distant from the part of the pattern that is relevant for extracting that data.

I propose that the when keyword be promoted to a form of pattern itself, a "guard pattern", that can be applied as a conjunctive pattern that applies an arbitrary boolean expression against the partially matched pattern and pattern variables. This would allow the conditions to be embedded within the recursive patterns.

if (obj is Datum { Value: string s when int.TryParse(s, out int value) } ) {
    // use value here
}

The existing uses of when as a pattern guard should automatically fall out as a legal pattern.

Open Questions:

1. When would these guards be executed and in what order.

[CyrusNajmabadi]

I like it :-)

[CyrusNajmabadi]

Open question to me is when these guards are executed.

[alrz]

This means there was something that couldn't be expressed with patterns themselves. Also with a when clause you would lose subsumtion checking and optimal codegen in a switch.

I'd suggest user-defined patterns for things like this. #4131

if (obj is Datum { Value: ParseInt(int value) } ) {
    // use value here
}

[DavidArno]

From my experience (which of course may not be typical), there are three two common use cases for when clauses (thanks to @chrisoverzero for pointing out my first case isn't a problem after all):

// 1. Working around the blanket ban on mixing or patterns and variable assignment
result = tuple switch {
(0 or 1 and var x, _) => do something with x... // not allowed to declare x here
(var x, _) when x == 0 || x == 1 => do something with x... // so we have to use when

// 2. Matching on types
result = typeof(T1) switch {
  T2 => // can't do this
  t when t == typeof(T2) => // have to do it this way
  
// 3. Needing to invoke a method as part of the pattern test
result = x switch {
  Datum { Value: var s } when int.TryParse(s, out var value) => do something with value ...

In the first case, hopefully the team will go back and look at or and not patterns and permit the use of variable declarations in such patterns in valid scenarios.

In the last case, as @alrz says, we could neatly solve these by supporting active patterns (which is a glaring hole in C#'s pattern matching features). How it's done is implementation details, but could indeed end up as something like @alrz suggests where any method fitting the pattern TryXXX(T1 inputValue, out T2 patternSite1 [, out T3 patternSite2 ... ]) can be treated as an active pattern, so (ignoring the int bit here as it's just an exampel) int.TryParse becomes:

result = x switch {
  Datum { Value: Parse(var value) } => do something with value ...

For the middle case, either pattern matching on types could be directly supported or an active pattern could be used here too.

So whilst I like the look of guard patterns, it makes sense to me to improve the interaction between or patterns and variable assignments and add support for active patterns first. Then we could better judge whether guard patterns are even needed.

[chrisoverzero]

Haven’t you forgotten your precedence rules?

// 1. Mixing or patterns and variable assignment
var result = tuple switch {
 ((0 or 1) and var x, _) => x + 2,
 _ => int.MaxValue,
};

SharpLab claims this is valid, at least.

[DavidArno]

Clearly I have forgotten the precedence rules as I'd expect or and and to have identical precedence and thus
(0 or 1) and var x and 0 or 1 and var x to be semantically identical. 😕

But you are right: they have different precedence and your version does indeed work. Thank you so much. That's quite made my day 😀