Pattern-matching changes for short tuples

[gafter]

Adjust the implementation of pattern-matching to reflect LDM resolutions from 2018-11-05. The last point will be included in the changes for #20648.

Deconstruction vs ITuple

Proposed:

1. If the type is a tuple type (any arity >=0; see below), then use the tuple semantics
2. if the type has no accessible instance Deconstruct, and satisfies the ITuple deconstruct constraints, use ITuple semantics
3. Otherwise attempt Deconstruct semantics (instance or extension)

Alternative

1. If the type is a tuple type (any arity >= 0; see below), then use the tuple semantics
2. If "binding" a Deconstruct invocation would finds one or more applicable methods, use Deconstruct.
3. if the satisfies the ITuple deconstruct constraints, use ITuple semantics

In both cases, 4. Error

Decision: Alternative

Proposed:

1. Permit pattern-matching tuple patterns with 0 and 1 elements (appropriately disambiguated as previously decided)

if (e is ()) ...

if (e is (1) _) ...
if (e is (x: 1)) ...

if (e is (1, 2)) ...

Conclusion: Approved

Proposed:

As part of this, I propose that we consider System.ValueTuple<T> instantitations to be considered tuple types. I do not propose any syntax changes related to this.

As part of this, I propose that we consider System.ValueTuple to be considered a tuple type. I do not propose any syntax changes related to this.

Conclusion: Approved

[alrz]

if (e is (1) _) ...

Currently, (var x) would give you an error, so this doesn't really matter, but when we have parenthesized patterns, removing _ from something like (var x) _ would completely change the semantics, while variable designation is optional anywhere else in patterns in a sense that it would have no effect on the pattern itself. IMHO, it shouldn't be encouraged, or even supported?

[gafter]

IMHO, it shouldn't be encouraged, or even supported?

I don't understand what you are proposing should or should not be encouraged or supported.

[alrz]

I'm saying that it should not be encouraged, as in, not suggesting in the error message (from #31056).

and perhaps should not be supported at all, because of the confusion that it may create (later with the possible introduction of parenthesized patterns).

[gafter]

Fixed in #31056