"not-or" pattern simplification without warning

[pinkfloydx33]

I ran into a little "quirk" of the not pattern while writing out what my brain originally told me was the equivalent of !string.IsNullOrEmpty:

var s = "";
if (s is not null or "") {
   Console.WriteLine(1): // prints 1!
} 

This took me a little bit to track down; I had to look at the compiled IL to see what was happening. This gets translated to a simple null check. If you read it (correctly) as s is not null or s is "" this makes sense since !a || b simplifies to !a.

The correct way to write this would be to either add parentheses or change or to and not:

var s = "";
if (s is not (null or "")) {
   Console.WriteLine(1): // not invoked
} 
if (s is not null and not "") {
   Console.WriteLine(1): // not invoked
} 

Once I tracked this down, I had an ah-ha moment. I'm not arguing the semantics of this as it does make sense to me now. However, I'm surprised that the compiler doesn't warn about the essentially dead code (nor did the IDE, though a different issue).

Assuming that the semantics are in fact correct, is it intentional we don't recieve some sort of warning here? (Is that even possible?) I don't think it would be uncommon for someone to read the first example "naturally" the way I did. This took me a little while to figure about and I wouldn't expect most developers to decompile the code if they hit this scenario.

SharpLab

It's incredibly difficult to search for terms like not and or so apologies if this has been discussed before. I also had trouble coming up with a title for this discussion, suggestions welcome.

[alrz]

not has a higher precedence than and or or so not null or "" is actually parsed as (not null) or "".

As for the warning, the compiler can and should flag unreachable patterns, as it is the case when you break that in a switch statement.

    public void M(string s) {
        switch (s) {
            case not null:
            case "": // error; can never match
                break;
        }
    }

Even if this is by-design, I think we should try to warn in those cases as part of a warning wave.