Remaining work for C# 9 pattern-matching changes

[gafter]

The following is the remaining work items not yet implemented for the C# 9 pattern-matching changes described in dotnet/csharplang#2850

• Update license comments in recently added files on the branch. (Implementation for *type*, not, and, or, and relational patterns #41503)
• Support relational patterns for decimal. (Implementation of relational patterns for decimal (C# 9.0) #41697)
• In the decision DAG builder, collapse states that have identical behavior so that the generated decision dag is simpler in some cases. (Optimize the decision dag by eliminating semantically identical states. #42012)
• In an and pattern, use the type from the left as the input type for the right. This requires some spec work.
• Overhaul the lowering of the is-pattern expression to support or, not, etc.
• Improve lowering (code gen) for a sequence of relational pattern tests. See Optimize switch code generation with relational operators via tree #42054
• The semantic model is not yet supported for relational operators (GetSymbolInfo and GetTypeInto for new pattern forms #42357)
• IOperation not yet supported for the new forms. (IOperation support for new pattern forms in C# 9.0. #42474)
• CFG for new pattern forms (Implement CFG for new pattern forms #42548)
• For the type pattern, we can give the same set of warnings as we do for the is type expression.
• Implement single-element ITuple-based positional pattern (once the open issue is resolved)
• Additional testing (see Test Plan for C# 9 pattern-matching improvements. #40727)
• Document the "breaking" change around completeness for enumerated byte and sbyte switches. (Document known breaking changes in C# 9.0. #42632)
• Are formatter changes required?
• Document breaking change: not is considered a type in C# 8 and a pattern in C# 9. (Document known breaking changes in C# 9.0. #42632)
• Document breaking change: and and or are allowed as variable names in C# 8, but are pattern combinators in C# 9. (Document known breaking changes in C# 9.0. #42632)

Open Issues

• What is the narrowed type for a for an or pattern? The current spec (common type) doesn't work as the common type permits representation-changing conversions (e.g. for int or long).
• Is e is dynamic a "pure" null check? [See is dynamic should be treated as a "pure null" check #40960 ; not a pattern-matching issue]

[alrz]

What syntactic forms are permitted for an ITuple-based recursive pattern, and how would you write a single-element ITuple-based pattern? There is no way to do it currently.

To my surprise, both of these work already.

var x0 = obj is (int i) _;
var x1 = obj is var (x);

[gafter]

@alrz Then I have to make sure they continue to work.

[gafter]

@alrz I was concerned about this not working:

_ = o is (int) _;

This does not work because the right-hand-side is interpreted as a cast expression, which casts _ to the type int. You would have to write this

_ = o is (int _) _;

which does work.

[alrz]

FWIW, another way to disambiguate would be o is ((int)) _
Rare but this will also work if we had named constants: o is ((constant)) _