- "It doesn't matter so much because it's already so bad"
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.
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.
#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.
Rules are adopted as written.