# C# Language Design Meeting for August 19th, 2024

## Agenda

- [Better conversion from collection expression](#better-conversion-from-collection-expression)

## Quote of the Day

- "So you're saying that element type is more equal than collection type?"

## Discussion

### Better conversion from collection expression

Champion issue: https://github.com/dotnet/csharplang/issues/8374  
Specification: https://github.com/dotnet/csharplang/blob/915dce8cd2a87a390904044ddada2d0794a15a24/proposals/collection-expressions-better-conversion.md

Today, we followed up from the [last time](LDM-2024-07-24.md#better-conversion-from-collection-expression-with-readonlyspant-overloads) we discussed collection expressions. This is a matter
with some urgency, as we want to try and solve the `ReadOnlySpan<string>` vs `ReadOnlySpan<object>` issue before .NET 9 ships. To do this, we looked at a proposal for introducing a new algorithm
for better conversion from expression, as it applies to collection expressions. The proposal tries to stick close to one of our
[previous principles](../2023/LDM-2023-09-20.md#overload-resolution-fallbacks) around collection expressions, which is that we didn't want to get pulled in opposite directions from the collection
type and the element type. To do this, and still enable disambiguation between `List<int>` and `List<byte>`, or other similar scenarios, we had to introduce a new concept around collection type
comparison, without type arguments. This concept is new to the language, and there is some amount of spec work that needs to be done on it. However, further discussion led us to question something
larger: the entire principle we previously stated, where we said we wanted scenarios like `IEnumerable<int>` and `List<object>` to produce an ambiguity error. This principle was based around the
idea that with collection expressions, both the type of the collection itself, as well as the type of the elements, are equal in priority. On further reflection, we're not sure this is actually
true. The collection expression doesn't have a type, and even when we eventually add a natural type, target-typing will always win, just like it does with switch expressions. On the other hand,
the elements _do_ have natural types, and those natural types can say a lot. Given `[1, 2, 3]`, we've come around to the idea that `IEnumerable<int>` is better than `List<object>`, based purely
on element type. This radically changes our thoughts on the direction this proposal needs to move; we'll come back next LDM with an updated proposal that takes this changed principle in mind,
prioritizing collection element type betterness over the collection type itself.

#### Conclusion

We will revisit an adjusted proposal that prioritizes element type over collection type betterness.
