Question

In the code below, I’ve defined two overloaded methods named Bar. In Foo(), I make three calls to Bar, and get an error on the third call.

The first two resolve to the expected overloads. The third however generated the following error:

The type 'string' cannot be used as type parameter 'T' in the generic type or method 'Bar<T>(T, string, params object[])'. There is no implicit reference conversion from 'string' to 'System.Exception'.

Clearly the third call is binding to “Bar()”, but failing to convert the first parameter to an Exception. It’s also clear that it is the second argument being a string that’s throwing off the compiler. When it’s not a string (case 2) the resolution is fine. But it seems obvious (to me) that the failing line should bind to “Bar()” (since the first parameter is unambiguously a string).

Can anyone explain why the compiler is using this binding? I would consider creative workarounds, but what I’m really looking for is an explanation of why this is happening. I spent some time with the C# language specification, but failed to find (i.e. gave up on) a clear answer. Obviously I can rename one of the Bar methods, or provide named arguments, or mark one of the parameters ref… but none of these is ideal for my specific scenario.

Not that it’s relevant, but I have written Java code that does exactly this, and the compiler had no problem.

The code:

public void Bar(string s, params object[] ps) { } // Call this "Bar()"
public void Bar<E>(E e, string s, params object[] ps) where E : Exception { } // Call this "Bar<T>()"

public void Foo()
{
    Exception e;
    Object o1, o2;

    Bar(e, "fmt {0}", o); // Resolves fine, as expected
    Bar("fmt {0} {2}", o1, o2); // Also resolves as expected
    Bar("fmt {0} {2}", "bar", o1); // Error!
}

Answer 1

The answer is that overload matching does not consider constraints. As to is this in the C# spec, I’m not completely sure. The matching always uses the most specific option and string as generic T is always more specific than string as Object (since it’s matching the actual type and not a child type). See Constraints are not part of the signature on Eric Lippert’s blog.

To make this work, if the constraint of exception is needed, use void Bar(Exception E, ...) if possible.