Allow left-side 'and', 'or' pattern

[kyoyama-kazusa]

Hi everyone! This topic will introduce the and and or patterns on the left side of the keyword is. In this way we can simplify the code:

Normal check

if (obj1 or obj2 is int) // obj1 is int || obj2 is int
{
    // ...
}

if (obj1 and obj2 is not null) // obj1 is not null && obj2 is not null
{
    // ...
}

if (value1 and value2 is >= 1 and <= 100) // value1 >= 1 && value1 <= 100 && value2 >= 1 && value2 <= 100
{
   // ...
}

Recursive pattern

if (obj is { Prop1 or Prop2: 100 }) // obj is { Prop1: 100 } or { Prop2: 100 }
{
    // ...
}

if (obj is { Prop1 and Prop2: not null }) // obj is { Prop1: not null } and { Prop2: not null }
{
    // ...
}

Thank you. If duplicate, sorry for that.

[theunrepentantgeek]

What problem does this solve?

Being terser isn’t in itself sufficient reason to introduce another way to do something that’s already possible.

[foxesknow]

Well, that's not true is it. For example, see:

• Expression bodies members
• Using statements within methods
• Top level statements (aka no need for Main)

[theunrepentantgeek]

There have been quite literally hundreds of suggestions for alternative C# syntax where the only motivation was to make things terser, shorter, more concise. Most of those go exactly nowhere.

The very few times those suggestions have gained traction and made it into the language are when their use is expected to be extremely common. For example:

• The vast majority of property get and set statements are single line, as are a significant number of method bodies.
• Most using statements within methods have a scope that ends at the end of the enclosing scope (often the whole method)

[TheUnlocked]

if (obj is { Prop1 and Prop2: not null }) // obj is { Prop1: not null } and { Prop2: not null }
{
    // ...
}

This isn't criticism of the proposal, but for and you can already write this with a few fewer characters:

if (obj is {Prop1: not null, Prop2: not null}) {
    // ...
}

[kyoyama-kazusa]

Thanks for your reply. In fact I mean in this way we can reduce the mistake of the value checking and simplification in code. Sometimes we want to check whether some properties are a same value, if we use and or or pattern, we can reduce duplicate code of that value:

if (obj is { Prop1: 10, Prop2: 10, Prop3: 10 })
{
}

For example, if we check whether three properties are all 10, we should write the value 10 three times. If the one value is changed to another value due to our carelessness, this will be a potential bug. "Left-side and pattern" may solve this problem.

if (obj is { Prop1 and Prop2 and Prop3: 10 })
{
}

At the same time, we will write the value 10 only once.

:)

[RikkiGibson]

This is an interesting idea, and I'd like to see a few things related to it:

1. Can you show some "slam dunk" scenarios where multiple values are provided as input to the same pattern, and doing so provides a significant boost to clarity or maintainability?
2. Can you show that this won't introduce ambiguity issues when is/and/or are composed?
3. Can you explain whether/how not would be used on the left side of an is?

[kyoyama-kazusa]

(1) I don't know which case is significant, so I cannot provide you with that example. Sorry :(

(2) The ambiguity case is the mixed usage of and and or together:

if (obj is { Prop1 and Prop2 or Prop3: 10 })
{
}

What does this mean? obj.Prop1 == 10 && obj.Prop2 == 10 || obj.Prop3 == 10? If we want to combine Prop2 and Prop3 first, should we add a brace?

(3) The reason I don't introduce not pattern on the left side of an is is that not pattern may be ambiguous.

if (obj is { not Prop: 20 })
{
}

What does this mean? "Not property is value" means all other properties in this instance are this value? I don't know. So I haven't introduce not pattern.

Thanks for your reply.

[BreyerW]

Simplest approach to not would be lowering to !(expr) but even then not before patterns reads weirdly im not sure if it worth adding it

[svick]

How would this interact with patterns that assign variables? Consider e.g. person1 and person2 is Student student. Would this check both expressions on the left, but then assign only one of them to the variable? Which one?

[BreyerW]

If it were me i would disallow assign pattern for this scenario. Type check pattern would be allowed.

Alternatively allow deconstruct pattern something like: person1 and person2 is Student (student1,student2) or person1 and person2 is (Student student1, Student student2)

[svick]

@BreyerW

For that specific case, (person1, person2) is (Student student1, Student student2) is already valid syntax, so I don't see the need to introduce tuple support here.

[BreyerW]

It wouldnt be the first time when you can do the same thing differently in c#, pattern matching is perfect example. That being said the only value is consistency and convenience but same thing can be said for many recent syntactic sugars