- "So you're saying that element type is more equal than collection type?"
Champion issue: #8374
Specification: https://github.com/dotnet/csharplang/blob/915dce8cd2a87a390904044ddada2d0794a15a24/proposals/collection-expressions-better-conversion.md
Today, we followed up from the last time 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 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.
We will revisit an adjusted proposal that prioritizes element type over collection type betterness.