IDE work items for c# 9.0 patterns.

[CyrusNajmabadi]

Language/Compiler work: dotnet/csharplang#2850 dotnet/csharplang#3361

These are the things we will need to support and/or validate:

• [Cyrus] Update features that do null checks do is not null. Use is not null check when available. #43322
• [Cyrus] Update existing pattern analyzers to try to use and, or, not patterns when appropriate. Supporting converting more switches to expressions if or-patterns are available #43324
• we need SymbolInfo/TypeInfo. This will ensure that quick-info goto/def/find-refs works. (See GetSymbolInfo and GetTypeInto for new pattern forms #42357)
• [Sam]Update fixer that adds discards to not patterns anymore (if the lang version is correct). Support type patterns in Convert If to Switch refactoring #43528, Support type patterns in Remove Unused Value #43540
• [Sam]Automatic Brace Completion needs to work for pattern parens. Add tests for pattern brace completion #43522
• [Compilers, Tomas] Properly classify debugger breakpoint spans for subexpressions. (good to go since Expression breakpoints for switch expression. #42711 and Active statements in switch expression #43154)
• [Compilers] Switch expression stepping not working correctly: Switch expression stepping not working correctly #43468 (Fix several issues with sequence points and switch expressions #43471)
• [Compilers] Check Interactive window ( Test new pattern forms in interactive. #43358)
• [Tomas] Test Active Statement tracking in switch expression arms (part of EnC, editing itself is still unsupported: Enable EnC of methods containing switch expressions #43099).
• [Compilers] Check with @gafter for the set of new diagnostics reported. (See IDE work items for c# 9.0 patterns. #42368 (comment))
• [Compilers] Make sure we don't crash on unreachable case diagnostics. (Added code to prevent the compiler crashing when this diagnostic is given. Joke. See Address some crashes found by fuzz testing. #43280)
• [Compiler] Ensure IOp works. (See IOperation support for new pattern forms in C# 9.0. #42474, Implement CFG for new pattern forms #42548)
• [Allison] Completion. We need it for not, and, or. Need to make sure we're at soft selecting in places where new comparison patterns are allowed so we don't interfere with typing. Add keyword completion for new C# 9 patterns #43365, Enable suggestion mode for certain cases in C# 9 pattern keyword completion #43574
• [Debugger] Disambiguate sequence points with equal text span: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1106749.
• [Cyrus] Add feature to convert from !(x is null) to x is not null. Updating our code-inverting tools to support inverting patterns. #43438
• [Cyrus] Update parentheses simplification and addition. Updating our code-inverting tools to support inverting patterns. #43438
• [Cyrus] Complexify/simplify. Updating our code-inverting tools to support inverting patterns. #43438
• [Cyrus] update invert-if to invert patterns. Updating our code-inverting tools to support inverting patterns. #43438
• [Sam] Formatting has to be updated to understand these constructs entirely. We have lots of options around whitespace around operators that will/won't apply when these are in patterns. e.g. (>= Implement formatting for C# 9 patterns #43538
• [David] Indentation. Add tests for indentation around C# 9 patterns. #43606
• Add feature to offer to use not null.
• Need to ensure that features that select subexpressions don't work on subpatterns (i.e. can't extract a portion of a pattern).
• [Sam][LowPriority]case string _ =>. Add analzyer that removes unnecessary _ .
• [Sam][Need Validation] Features based on unbound types. i.e. Add Using, Generate type.
• Add missing cases.
• [Cyrus] Validate TypeInferrer
• [Sam] split/merge ifs (likely do not support anything here)
• we would take a refactoring to convert to/from if-chains to and/or patterns
• would take a refactoring to convert long chains of comparisons to patterns.

[jinujoseph]

cc @mikadumont for info

[alrz]

we would take a refactoring to convert to/from if-chains to and/or patterns
would take a refactoring to convert long chains of comparisons to patterns.

Some other ideas for refactorings:

• Convert subsequent switch case labels to or patterns
  case p: case q: -> case p or q:
• Convert subsequent switch case labels to relational+and patterns
  case 'a': .. case 'z': -> case >= 'a' and <= 'z':

These might be useful to simplify current workarounds:

• Convert switch expressions to is+or patterns if applicable i.e. all arm values are boolean constants
• Use or-patterns in switch expression arms if applicable i.e. there's some identical arm values

Some of these might overlap though, and we should decide which one should be an analyzer versus a refactoring.

case string _ =>. Add analzyer that removes unnecessary _ .

I think this should be in the simplifier. There are other cases that need to be covered there.

Update existing pattern analyzers to try to use and, or, not patterns when appropriate

This should include if-to-switch and switch-statement-to-expression in particular, those are specifically limited due to lack of or-patterns.

Worth to consider:

• fade out default: when the switch is already exhaustive.
• fix overlapping/redundant relational patterns if the compiler doesn't complain e.g. =>2 and =<4 or =>3 and =<5

[CyrusNajmabadi]

great stuff. Thanks @alrz !

[gafter]

New diagnostics for pattern-matching in C# 9.0

CS8780 ERR_DesignatorBeneathPatternCombinator

You aren't permitted to declare a pattern variable under an or or not
pattern combinator, so we produce this error when you attempt to do so.

  if (o is int or long l)        // error: A variable may not be declared within a 'not' or 'or' pattern.
  if (o is Bar { F: not int i }) // error: A variable may not be declared within a 'not' or 'or' pattern.

CS8781 ERR_UnsupportedTypeForRelationalPattern

The new relational patterns work only for the built-in types that
have comparison operator. If you attempt to use them for other
types it is an error

  string s = ...;
  if (s < "aardvark") // error: Relational patterns may not be used for a value of type 'string'.

CS8782 ERR_RelationalPatternWithNaN

The new relational patterns do not permit comparing with NaN.

  double d = ...;
  switch (d)
  {
      case < double.NaN: // error: Relational patterns may not be used for a floating-point NaN.

CS8793 WRN_GivenExpressionAlwaysMatchesPattern

When a new pattern form always matches in an is-pattern expression because the input is a constant, we warn.

  if (1 is < 10) // warning: The given expression always matches the provided pattern.

CS8794 WRN_IsPatternAlways

When a new pattern form always matches in an is-pattern (whether or not the input is a constant), we warn:

  int x = ...;
  if (x is <= int.MaxValue) // warning: The input always matches the provided pattern.

[tmat]

Active statement tracking in switch expression arms works well.
Found a couple of related issues:
[Debugger] Disambiguate sequence points with equal text span: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1106749.
[Compilers] Switch expression stepping not working correctly: #43468

[alrz]

[Sam][LowPriority] case string _ =>. Add analzyer that removes unnecessary _ .

@sharwell I can take this if you're not working on it.

@CyrusNajmabadi

A langversion-dependant reducer works here without a need for an analyzer, right?
(much like CSharpDefaultExpressionReducer)

[sharwell]

@alrz Sure go ahead! Also consider the following case, which is not new for C# 9 but would benefit from the same simplification:

if (o is string _)

[CyrusNajmabadi]

Closing out. Any remaining work/enhancements can come through directed issues.

[julealgon]

@gafter

You aren't permitted to declare a pattern variable under an or or not
pattern combinator

Can you point me to more documentation on this limitation?

I just stumbled upon it on a scenario where it didn't make a lot of sense to me:

if (x is { Code: not 1 code })
{
    return new Error(code);
}

The value 1 above is a "success" indicator in my domain, and I want to match "when the code is not 1" then generate an error with the actual code in it.

Can you elaborate why this is an invalid scenario? The restriction you mentioned doesn't seem to make sense when using constant values on the match IMHO.

Seems like the only way out of this is degrading the code into using a when like:

if (x is { Code: var code } when code != 1)
{
    return new Error(code);
}

FAKE EDIT:

Found a really weird (undocumented?) way of extracting the value, by repeating the same property twice:

if (x is { Code: not 1, Code: var code })
{
    return new Error(code);
}

[CyrusNajmabadi]

Can you elaborate why this is an invalid scenario?

Because nothing in the language allows it. Neither hte 'not' nor 'constant' patterns allow you to name the result. We'd need a proposal allowing that for that to work :)

Found a really weird (undocumented?) way of extracting the value, by repeating the same property twice:

Now that is weird. @333fred @jcouv is that supposed to be allowed? Seems really really strange and unintentional.

[333fred]

Huh. I agree it's odd, but I don't see anything in the spec that would disallow this: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-8.0/patterns.md#property-pattern.

[alrz]

@julealgon Try:

if (x is { Code: not 1 and var code })
{
    return new Error(code);
}

[julealgon]

Now that is weird. ... Seems really really strange and unintentional.

I agree @CyrusNajmabadi . I honestly thought it would give me some sort of error at runtime the first time I tried it, or match the values incorrectly.

@julealgon Try:

if (x is { Code: not 1 and var code })
{
   return new Error(code);
}

It works @alrz ! Interesting... is that how it is supposed to be done at the end of the day? I don't think I've ever seen an example like that.

[CyrusNajmabadi]

is that how it is supposed to be done at the end of the day?

Yes. This is definitely a supported and used pattern today. In the future, we might consider a way of making this more terse. But absent that, the above is def a realistic way to go.

[Thaina]

@gafter

CS8780 ERR_DesignatorBeneathPatternCombinator

You aren't permitted to declare a pattern variable under an or or not
pattern combinator, so we produce this error when you attempt to do so.

  if (o is int or long l)        // error: A variable may not be declared within a 'not' or 'or' pattern.
  if (o is Bar { F: not int i }) // error: A variable may not be declared within a 'not' or 'or' pattern.

I wish this would be allowed

object obj = 1;
if(obj is not int i or <= 0)
    return;

// Do something with i when i is positive integer

[333fred]

@Thaina I expect that would fall out of dotnet/csharplang#4018.