Behavior difference between "a is not X" and "!(a is X)" patterns

Version Used: Visual Studio 2022 v17.2.4

Steps to Reproduce:

1. Have a !(variable is ClassName) pattern in a context where ClassName is also a property name.
2. Invoke the CodeFix for IDE0083 to convert this to an is not pattern.
3. Compilation fails after this.

See sharplab snippet:

using System;
using System.Linq.Expressions;

public class C {
    private string LambdaExpression { get; set; }
    public void M() {
        Expression expression = null;
        if (!(expression is LambdaExpression))
            Console.WriteLine("1: not a lambda expression");
        // error CS0029: Cannot implicitly convert type 'string' to 'System.Linq.Expressions.Expression'
        // this one picks up the string property, rather than the type
        //if (expression is not LambdaExpression)
        //    Console.WriteLine("2a: not a lambda expression");
        if (expression is not LambdaExpression _)
             Console.WriteLine("2b: not a lambda expression");
        if (expression is not System.Linq.Expressions.LambdaExpression)
            Console.WriteLine("3: not a lambda expression");
    }
}

Expected Behavior: Either:

1. Code still compiles afterwards, or
2. The CodeFix for IDE0083 does not convert the expression.

Actual Behavior: Code fails to compile after invoking the CodeFix, because it attempts to match against the property name (or its value?) I’m not sure what it is even trying to do there, because it can’t possibly be parsed as constant pattern; and it doesn’t match as a type pattern (which would be the expected thing). It does work if I add a variable name or discard at the end (which turns it into a declaration pattern).

[jcouv]

This is expected from the language/compiler side and results from backwards compatibility concerns with is expressions which predate patterns.

From the patterns doc: “Pattern matching introduces a new context where the expression-type ambiguity arises. Previously the right-hand-side of an is operator was a type. Now it can be a type or expression, and if it is a type it may be followed by an identifier.”

In other words, an is-expression previously would only bind to a type (and this has to be maintained for compatibility reasons), but an is-pattern can bind to a type or a (constant) expression.

I’m moving this issue to the IDE. Let’s see if we can avoid offering the fix in this situation.

[BhaaLseN]

Oh, sorry, I misunderstood that.

Yes, I just tried this on a test project, I get the refactoring “Use pattern matching” für IDE0083 in both cases (property in a base class, property in the same class). Both cause compilation to fail.