Proposal: list-patterns on enumerables

[jcouv]

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

Champion issue: #9005

Background:

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

Design meetings:

• https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-10-19.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-09.md#list-patterns-on-enumerables

[Xyncgas]

why not [1; x] [1; x; 5]
since it's a new language proposal, we can throw away that var, similar to how we can write lambda without type name on its parameter, it just matches
maybe we can even do var myLambda = [1; x] => true | unmatched => false; myLambda(myList);

[KennethHoff]

It's not a new language feature. It already exists for indexable collections, like arrays and lists.

[En3Tho]

[1; x] feels like a (personally) long awaited pattern matching on non const values rather that x being a declared variable here. Also, as stated above it's already a feature on indexable types. It's just that it's harder to do properly with sequences because it most likely will result in implicit buffering in complex cases like [1, ..var x, 5] which might be not desirable. At least with indexable collections this behavior is explicit and based on public members of those collections.

[jnm2]

Proposal revamped: https://github.com/dotnet/csharplang/pull/9165/files?short_path=842dc5b#diff-842dc5be20dd67a91231b72c300d0bc365040809d32c98dee0e4e166e53191bc

[smarts]

I know that languages have to walk the fine line between "pit of success" for developers and providing useful/powerful features that have potential for misuse. I could go either way on this one, but my question to the community is which side of the line people fall on for this feature?
Is it useful? Of course.
Does it encourage anti-patterns? At the very least it's making the multi-enumeration scenario easier, which is usually frowned upon because of deferred execution. At its worst it's relying on repeatable enumeration which isn't guaranteed for purely deferred enumerables nor collection-backed enumerables (because non-indexed collections should be seen as unordered and therefore don't need to provide repeatable enumeration - Note: a new interface might help here, but that's a separate issue).
Is it more useful than harmful? Probably, but I just wanted to enumerate some of the concerns. (pun intended)

[timcassell]

I think the only issue would be if it's used in a switch expression. The compiler would need to ensure all switch arms being checked will only enumerate once. As opposed to if else if, which I assume would necessitate multiple enumeration.

[jnm2]

Yes, the slice pattern can be much worse than .Any() if you consider a very large amount of items in the collection.

@smarts The proposal recommends against allowing subpatterns on the slice pattern for this reason. .. in the pattern will not materialize a new collection for the items it matches against.

I think the only issue would be if it's used in a switch expression. The compiler would need to ensure all switch arms being checked will only enumerate once. As opposed to if else if, which I assume would necessitate multiple enumeration.

@timcassell This is an excellent point, I'd like to understand whether there are guarantees like this for switches currently. I'm not sure there are. If there are, that would mean that the refactoring from switch to if could introduce multiple enumeration where it wasn't before.

[jnm2]

I'm not sure whether the following scenarios could realistically be implemented without multiple enumeration. I'm leaning towards letting it be multiple enumeration since there are multiple patterns, and just letting analyzers point this out:

obj switch
{
    { Enumerable: [], OtherProp: 1 } => ...
    { Enumerable: [1] or [2, 3], OtherProp: 4 } => ...
}

Let's just let this be enumeration three times, and you don't do this unless you'd do the same with .Any() and .SequenceEqual etc calls.

[jnm2]

It sounds like it might be possible to guarantee no multiple enumeration across switch branches and or/and patterns. That does make it more interesting.

[HaloFour]

I guess that depends on how complicated the compiler wanted to get. It's already capable of avoiding reevaluating patterns that appear anywhere within the switch more than one time, I don't see why it couldn't technically handle that combination of patterns with a single enumeration that attempts to advance at most 3 times. It could even decide that evaluating the OtherProp patterns would make it easier/cheaper to apply the list patterns.