I just noticed a strange behavior with overload resolution.
Assume that I have the following method :
public static void DoSomething<T>(IEnumerable<T> items)
{
// Whatever
// For debugging
Console.WriteLine("DoSomething<T>(IEnumerable<T> items)");
}
Now, I know that this method will often be called with a small number of explicit arguments, so for convenience I add this overload :
public static void DoSomething<T>(params T[] items)
{
// Whatever
// For debugging
Console.WriteLine("DoSomething<T>(params T[] items)");
}
Now I try to call these methods :
var items = new List<string> { "foo", "bar" };
DoSomething(items);
DoSomething("foo", "bar");
But in both cases, the overload with params
is called. I would have expected the IEnumerable<T>
overload to be called in the case of a List<T>
, because it seems a better match (at least to me).
Is this behavior normal ? Could anyone explain it ? I couldn't find any clear information about that in MSDN docs... What are the overload resolution rules involved here ?
Section 7.4.3 of the C# 3.0 specification is the relevant bit here. Basically the parameter array is expanded, so you're comparing:
and
The
T
for the first match is inferred to beList<string>
and theT
for the second match is inferred to bestring
.Now consider the conversions involved for argument to parameter type - in the first one it's
List<string>
toList<string>
; in the second it'sList<string>
toIEnumerable<string>
. The first conversion is a better than the second by the rules in 7.4.3.4.The counterintuitive bit is the type inference. If you take that out of the equation, it will work as you expect it to:
At that point, there's only one applicable function member in each call.