dotnet/roslyn

Potential source breaking changes due to params collection

hez2010 opened this issue · 3 comments

Version Used: 9.0.100-preview.6.24304.2

Steps to Reproduce:

string.Concat(["a", "b"]);

Diagnostic Id: CS0121

Expected Behavior: No compilation error

Actual Behavior:

CS0121 The call is ambiguous between the following methods or properties: 'string.Concat(scoped ReadOnlySpan<object?>)' and 'string.Concat(scoped ReadOnlySpan<string?>)'

Note that this is a source breaking change from C# 12 where the code used to compile.

@cston I believe this is the issue you were mentioning to me. We should see what the spec says and if we got it wrong in the spec or the impl. My expectation would 100% be that ROS<T> is better than ROS<U> when there is an implicit conversion from T to U. Just like void X(T t) is better than void X(U u) when dealing with a single element.

I'm thinking we might have spec'ed this wrong, but the above was definitely the intent. :)

My expectation would 100% be that ROS<T> is better than ROS<U> when there is an implicit conversion from T to U.

Currently, better conversion rules for collection expressions treat this case as ambiguous.

Perhaps there should be an additional rule to prefer System.ReadOnlySpan<T> over System.ReadOnlySpan<U> for a collection expression if an implicit conversion exists from T to U.

Note that this is a net9.0 only problem, or at least primarily. If we do take changes here to betterness think that we need to consider typing it to langversion 13