# C# Language Design Meeting for January 31st, 2024

## Agenda

- [Relax "enumerable" requirement for collection expressions](#relax-enumerable-requirement-for-collection-expressions)
- [`params` collections evaluation orders](#params-collections-evaluation-orders)

## Quote of the Day

- "It doesn't matter so much because it's already so bad"

## Discussions

### Relax "enumerable" requirement for collection expressions

https://github.com/dotnet/csharplang/issues/7744

We started today by looking at a proposal to relax the requirement that types attributed with `CollectionBuilderAttribute` be enumerable in some fashion, as defined by `foreach`.
This was done because want the type to "signal" that it is a collection type, and to give the specification some way of determining the element type of the collection, which we
do by looking at the iteration type from enumeration. However, a few cases have since been brought up of what are essentially collection builder types; they cannot be directly
enumerated, but can be materialized into iterable collections, and it may be idiomatic for us to allow using collection expressions to construct them. We could therefore use
`CollectionBuilderAttribute` as an explicit signal that the type it's applied to is a collection of some kind. We then need to figure out how we update the spec to account for
this, given our current heavy use of the "iteration type throughout. We also need to consider what to do when the iteration type and the type of a create method don't line up.
For both of these scenarios, we're currently thinking that we should maintain backwards compat; ie, if the collection defines an iteration type, then that's the one that's
preferred, as today. This would just be a fallback rule in the case that no iteration type was defined. However, the exact rules to flow through the rest of the spec will need
to be looked at by the collection expressions working group and brought back as a more complete proposal, as they're more complex than what was initially brought today.

#### Conclusion

The proposal is approved and put in the working set, and we will work on the specific wording as part of the collection expression changes in C# 13.

### `params` collections evaluation orders

https://github.com/dotnet/csharplang/issues/7700  
https://github.com/dotnet/csharplang/blob/951276cbc2f0ec3d688747109e904a3ddd6b29c5/proposals/params-collections.md#order-of-evaluation-with-non-array-collections-in-non-trivial-scenarios

Lastly today, we looked at evaluation orders for `params` collections in several non-trivial nested examples. In general, we approved the proposed rules without significant
discussion. The main point of evaluation was around how reuse of the collection will differ from how `params` arrays work in nested indexers in object initializers. The existing
`params` array behavior is, as far as we can tell, actually unspecified behavior in C#; the spec appears to permit reuse of the array instance, but it does not require it. We think
that for `params` collections, we can do better, but we do not currently intend on changing the behavior of `params` arrays.

#### Conclusion

Rules are adopted as written.
