Open issue: list-pattern questions for 9/20/2021

[jcouv]

1. confirm breaking change for property pattern Length/Count on countable/indexable type (non-negative assumption)
   intArray is { Length: -1 } // error CS8518: An expression of type 'int[]' can never match the provided pattern.

2. confirm interaction between list-pattern and ITuple.
   Proposal is to de-alias the elements, so (1, 2, 3) subsumes [1, 2, 3]. The k-th element of an ITuple and the k-th element of the list are equivalent.
   If we do this, should we do it when the positional pattern works on the basis of Deconstruct?

3. confirm that [ .._ ] requires a sliceable type, whereas [ 1, .. ] doesn't.
   "A slice_pattern with a subpattern is compatible with any type that is countable as well as sliceable."

4. confirm canonical formatting for slices
   e is [ first, .. var rest ] (space)
   e is [ first, ..var rest ] (no space)

5. gauge interest on some related features that might be considered for C# 11:

   • list-pattern on IEnumerable (spec https://github.com/dotnet/csharplang/blob/main/proposals/list-patterns-enumerables.md)
   • indexer/property pattern ({ [0]: var x })

6. re-iterate that we don't want/need a special length-pattern { length: ... } (just use Length: with new assumptions)

Relates to championed issue #3435
Relates to test plan dotnet/roslyn#51289

[jcouv]

Summary from LDM 9/22/2021:

1. let's try to only produce a warning for such cases
2. no interaction between list-pattern and ITuple
3. current spec sounds good (empty slice pattern doesn't require type to be sliceable)
4. format slice pattern with space
5. we will do our best to do list-patterns on IEnumerable in C# 11 (together with list-patterns). We will create a championed issue for indexer/property pattern
6. we're not championing a length: pattern

[jnm2]

4. format slice pattern with space

So, not like a list of ranges would look then: new List<Range> { .., 1..2, ..3 } Hmm.

[333fred]

Notes: https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-22.md#open-questions-in-list-patterns

[alrz]

[2] However, we think that this results in weird interactions with regular ValueTuple instances.

It won't. ValueTuple is already a special case and doesn't use ITuple pattern semantics which only applies to a positional pattern on object or ITuple-conforming types; the latter is the only match that is affected by the change. In any case, direct ValueTuple matches won't be affected. In any other case, deconstruction takes precedence, like for Tuple<> types, so it won't affect those either.

[1] Try to make it a warning for non-subsumed cases.

I think this is intended to follow explicit/implicit null test design, however, it's different in that the designated value-set is causing the error, not the test itself so it's without precedents. This will need a proposal on how exactly we're going to achieve that and what is the expected behavior in various scenarios.

[333fred]

ValueTuple is already a special case

We noticed. However, we didn't feel like it was worth adding a special case to list patterns to resolve the problems I mentioned.

This will need a proposal on how exactly we're going to achieve that and what is the expected behavior in various scenarios.

@jcouv had some ideas on how we can modify the nonnegativeinteger value set.

[jcouv]

I'm happy to take a stab at the proposal to reduce { Length: -1 } break.
We'd make the non-negative-integer value set contain all integers, but we'll consider it exhausted if all the non-negative values have been checked. This way, we'll error if you test for -1 twice, and we can just warn if you test for -1 once. We'll probably have to expand the general API of value sets to achieve this.

[333fred]

And we'll have to be careful about when we warn. For example, <5 should be fine, but <0 should result in a warning.