Allow expression is not Type { Prop1: pattern1 } or { Prop2: pattern2 } (property patterns after not Type or in pattern matching)

[tats-u]

Pattern matching allows expresion is Type { PropOfType1: pattern1 } and not { PropOfType2: pattern2 }, but doesn't allow its negative form expresion is Type { PropOfType1: not pattern1 } and not { PropOfType2: not pattern2 }.
We have to write expresion is not (Type { PropOfType1: pattern1 } and not { PropOfType2: pattern2 }) instead so far.
expression is Type { ... } or { ... } is helpful if you're going to use early-return/continue or throw an exception.

if (something is not DesiredType { Prop1: not null} desiredTypeValue or { Prop2: < 0})
    return false;

// do something on desiredTypeValue

return true;

This will be transpiled to:

DesiredType? desiredTypeValue = something as DesiredType;
if (desiredTypeValue is null || desiredTypeValue.Prop1 is null || desiredTypeValue.Prop2 < 0)
    return false;

// ...

return true;

We have to write instead so far:

if (something is not (DesiredType { Prop1: not null} desiredTypeValue and not { Prop2: < 0}))
    return false;

// do something on desiredTypeValue

return true;

https://sharplab.io/#v2:EYLgtghglgdgPgAQEwEYCwAoTCDMACAJwFMBjAewIBM8AxMsgClgBc8BBAGjxbwCEueAYQExWAERGsAogEoA3NnzI8gvAG9MeLXlx5g9ADZ4AsgzLAAVqVYBnGes3anCAOx4b3DzDKsGdMngQMNTerGrsIHgoeAC+gcHqfJGheEix8o5aMZk6+PpkRsZIZpbW7vYaGE7Obh5QXj54fvSJbJEoMRlV2tndWrr5hTglViS2FTk17p54Kc0B4W2zjdFxQdThvMmNSJ0KfbE5A4Z4AHIjZXYOB1N1Daz+eBSt26yrTwSJW6mx+069zjyJ1OxXMo3G12q2lc03qyweLUW7V+OV6MSAA==

[333fred]

This works fine: Edit: Nevermind, I see I misread the desired pattern (which doesn't speak well to the readability of the desired semantics). Where do you expect that you could use that desiredType variable?

[TahirAhmadov]

I've also read it a few times and can't understand what's going on. 🤣

[tats-u]

@333fred As long as you continue other patterns with or and don't bump into an external and.

variableName in Type { ... } variableName without a leading not is valid while trailing other { ... } patterns come with and.

variableName in not Type { ... } variableName should be treated like that but and and or must be swapped (c.f. De Morgan's laws).

leading not?	wanted chaining operator	unwanted external operator
No	and	or
Yes	or	and

if (obj is Complex { Imaginary: 0 } positive and not { Real: <= 0 } ) // you can use `positive` in `if`
{
    // you can use positive here
}
if ((obj is Complex { Imaginary: 0 } positive and not { Real: <= 0 } or double) // real is invalid due to the external `or double`
{
    // Complex value `positive`? or double value? Indeterminate.
}

// ↑ inverted ↓

if (obj is not Complex { Imaginary: 0 } positive or { Real: <= 0 } ) // you can use `positive` in `else` of `if`
{
    // you can't use positive here
    // - not Complex
    // - imaginary value
    // - negative or zero value
}
else
{
    // you can use `positive` here
}
if ((obj is (not Complex { Imaginary: 0 } positive or { Real: <= 0 } ) and not double) // positive is invalid due to the external `and not double`
{
    // you can't use positive here
    // - not Complex or double
    // - imaginary value
    // - negative or zero value
}
else
{
    // Complex or double. Its type is indeterminate.
}

[333fred]

Yeah, I'm ok with that not being usable. These patterns aren't readable.

[tats-u]

The above code is redundant because the second { ... } can be merged into the first ones.
Typical use case is the number of properties in the second { ... } is more than one like:

if (expression is not Type { Prop1: wantedPattern } or { Prop2: unwantedPattern1Of2, Prop3: andAlsoUnwantedPattern2Of2 })
    throw ArgumentExcpetion(nameof(expression));

I think it's as readable as:

if (expression is not (Type { Prop1: wantedPattern } and not { Prop2: unwantedPattern1Of2, Prop3: andAlsoUnwantedPattern2Of2 }))
    throw ArgumentExcpetion(nameof(expression));

because of the extra parenthesis and the nested not.