Proposal: list pattern

[gafter]

Allow is [ 1, 2, 3 ] (list pattern), is [length] (length pattern) and is [ 1, ..var x, 5 ] (slice pattern).

Speclet: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/list-patterns.md

See #3245

LDM Discussions:

• https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-14.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-16.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-02-03.md#list-patterns-on-ienumerable
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-04-12.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-07.md#list-patterns
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-14.md#list-pattern-syntax
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-21.md#list-patterns-in-recursive-patterns
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-22.md#open-questions-in-list-patterns
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-22.md#open-questions-in-list-patterns
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-13.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-20.md#open-questions-in-list-patterns
• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-09.md#ambiguity-of--in-collection-expressions

[HaloFour]

Awesome. Is this going to build on the linked proposal (with your additional feedback) or is this to track the work of designing list/collection/dictionary/etc patterns in general?

[gafter]

@HaloFour This is to track answering questions like those.

[alrz]

list/collection/dictionary/etc patterns

I wonder how you'd imagine dictionary/indexer patterns work and what use cases you have in mind.

Syntax-wise it could be {[constant]: pattern} but that's useless because any common type that exposes an indexer, throws if it's out of range.

[gafter]

Maybe we could use a TryGet method.

[alrz]

To me, that's too specific to have a dedicated syntax for. I think we should enable patterns for all Try-like methods which is essentially what user-defined positional patterns are.

map is TryGetValue("constant key", pattern) // maybe with another name

This could made to work only on "some" methods as mentioned in #1047 (comment)

Syntactical symmetry with indexer initializers makes it attractive though, however, the fact that it would not call the indexer might be confusing.

[HurricanKai]

Would this allow something like

Array: { Length: 1, [1] }

checking whether there is only one element and whether that element is 1?
Also, looking at the PR it's unclear to me whether this would allow checking for just the 5th element for example? Looks like that's not possible?

[alrz]

@HurricanKai

The pattern [1] already includes the check for length=1 so you don't need to add anything else.

To match Nth element you could prepend N-1 discards - it tends to get long but it is definitely possible.

The team is interested in supporting indexers, so using range indexer pattern, we could support { [5]: var elem } and generate e.Length >= 5 && e[5] is var elem (we'd only accept constant indexer args so we can calculate the minimum size).

I'm not sure if that's common enough for a dedicated support, plus it won't work with generic dictionaries which is probably a deal breaker.

[HurricanKai]

I'd generally much prefer [idx]: { ... } because it looks much more natural inside of more pattern matching, in fact I tried typing it out like that today cause I thought it would work 😄 ie [2]: { [5]: { Length: 5 } } on a string[][] would be quite amazing if possible.