# C# Language Design Meeting for October 19th, 2022

## Agenda

- [Open questions in list patterns on `IEnumerable`](#open-questions-in-list-patterns-on-ienumerable)
    - [Allowing patterns after slices](#allowing-patterns-after-slices)
    - [Allowing slicing to capture](#allowing-slicing-to-capture)

## Quote of the Day

- "You should be able to criticize your own children." "All your children are terrible"

## Discussion

### Open questions in list patterns on `IEnumerable`

https://github.com/dotnet/csharplang/issues/6574  
https://github.com/dotnet/csharplang/pull/6365

Today, we took a look at the list patterns on `IEnumerable` proposal, and looked through a few open questions on the topic.

#### Allowing patterns after slices

The first open question is whether we should allow patterns to follow a slice, such as `enumerable is [1, 2, .., 3]`. There's a few main concerns with allowing this: it will
significantly complicate the implementation of the emitted code, it could be a potential footgun for infinite `IEnumerable` scenarios, and, depending on implementation strategy,
it could actually perform _worse_ than equivalent LINQ code would, as LINQ does typechecks for underlying types and uses indexing when possible. For the first point, we're not
overly concerned: the user would have to write equivalent code, and has more opportunity to introduce bugs when doing so, whereas a generalized and tested compiler solution is
likely more robust. The second problem we're also somewhat okay with: the footgun has existed since .NET 1.0, with `IEnumerable` and `foreach`. New places things can be enumerated
continue to have this footgun, but it's always the same one.

The last concern though, that using a list pattern might be less efficient than using LINQ, is a big one. We're okay with the infinite enumerable issue, but we don't want patterns
to be avoided because they're seen as the least-efficient way to implement a check. We should be able to optimize these checks for when the underlying `IEnumerable` _doesn't_ need
to be fully enumerated to retrieve individual elements. We were planning on implementing a helper for doing these enumerations, and we should work with the BCL team to ensure that
it is as efficient as it can be. For example, LINQ has internal interfaces that it uses to back queries depending on whether the original enumerable was list-like, and it would be
good to have list patterns be able to take advantage of the same optimizations that Select or IndexOf can.

##### Conclusion

We're okay with restricting patterns after slices for now, but we should plan on having them eventually, and work with the BCL team to put a helper (type or set of methods) into the
standard libraries that list patterns can use for being as efficient as possible without tying the language to implementation details of specific frameworks.

#### Allowing slicing to capture

Finally, we looked briefly at whether or not a slice pattern on an `IEnumerable` should be able to capture the sliced section. One concern with this is that it would violate the
standard way we do slicing: a `Slice` method should return an instance of the same type it was called on. Slicing an array returns an array, slicing a Span returns a Span, etc. But
we couldn't do that here, as the underlying `IEnumerable` could be anything. It would also be weird if we allowed this when we don't allow slicing to capture for any list pattern:
we only allow slicing for types that are countable, indexable, _and_ sliceable. We think that, after we work through a helper type to address the first point, we might be in a better
position to determine whether we should generally expand slicing support to all list patterns, or whether we don't think that should be generally supported in any non-sliceable
input context.

##### Conclusion

We'll revisit after the helper type is designed and we have a better idea on efficiency.
