C# Language Design Meeting for December 10th, 2025

Agenda

• Collection expression arguments

Quote of the Day

• "It's almost like it's been a few weeks and we're a bit rusty." "We're not Rusty, we're C#y"

Discussion

Collection expression arguments

Champion issue: https://github.com/dotnet/csharplang/issues/8887
Spec: https://github.com/dotnet/csharplang/blob/34a80fa9cfef3bfe3bcb66c412928c4d6bd735b4/proposals/collection-expression-arguments.md
Diff: https://github.com/dotnet/csharplang/commit/2afe544f5facf319b3d76a044bf58d07349ce5b9

Today, we wanted to validate an assumption made during implementation, that the specific constructors we expose for IList<T> and ICollection<T> are constructors from List<T>. After some discussion, we think that this is ok to do, and will extend to IDictionary<TKey, TValue> as well for dictionary expressions. The main thing we want to update is that the spec itself won't care about the name of the parameter. If some version of the BCL decides to name capacity differently, then it is free to do so; users of that BCL would have to specify that different name instead of capacity.

Conclusion

The candidate signatures for IList<T> and ICollection<T> bind to the constructors with the corresponding signatures in List<T> when constructing the value. The spec will not say the names of these parameters, it will only specify the parameter type.