Champion "and, or, and not patterns" (VS 16.8, .NET 5)

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

The idea is to add three new pattern forms

1. pattern and pattern
2. pattern or pattern
3. not pattern

The latter two would not be permitted to define pattern variables in the subpatterns (as they would never be definitely assigned).

We'd have to decide on syntax and precedence, and whether some mechanism such as parentheses could be used for grouping patterns to override precedence.

Examples:

switch (o)
{
    case 1 or 2:
    case Point(0, 0) or null:
    case Point(var x, var y) and var p:
}

[alrz]

The latter two would not be permitted to define pattern variables in the subpatterns

For or patterns, as mentioned in #118 we can allow "identical types" for overlapping pattern variables,

switch (o)
{
    // x must be of the same type in both patterns

    case Point(0, var x):
    case Point(var x, 0):
        break;

    case Point(0, var x) or Point(var x, 0):
        break;
}

Alternatively we could use the "most specific common type" for overlapping variables,

switch (o) {
  case A x:
  case B x:
    CommonBase c = x;
    break;
}

but just identical-types would be still useful most of the time as demonstrated by F#.

[HaloFour]

I'm with @alrz, I think that allowing the operands of the or patterns to introduce pattern variables would be a powerful feature with the requirement that the pattern variables must have the same type and must be assigned by both sides.

[bondsbw]

An alternative to "most specific common type" is the intersection type A | B.

[MgSam]

I vote for using &&, ||, ! and not introducing yet more operators that do almost the exact same thing.

[HaloFour]

@MgSam

IIRC that would introduce ambiguities when patterns are used as Boolean expressions.

dotnet/roslyn#6235

[ufcpp]

Are intersection and union types too difficult to implement?

[yaakov-h]

Since the first two join two separate patterns, am I correct in understanding that the following would be valid?:

if (o is IDictionary d and IEnumerable e) {
    // object.ReferenceEquals(d, e) == true
    // (assuming no boxing)
}

if (o is IDictionary and IEnumerable e) {
    // e is IEnumerable only, there is no IDictionary variable created
}

[gafter]

@ufcpp How would intersection and union types help with case 1 or 2:?

[gafter]

@yaakov-h Regarding your first example, yes. The second example doesn't make sense as IDictionary is not a pattern.

[Unknown6656]

Also consider implementing xor patterns (or ^ if one does not like the word xor).
It would of course -as with or- not be permitted to define pattern variables.

[jnm2]

Also consider implementing xor patterns

Why?