Strange C# compiler behavior when choosing overload that looks like a bug/missing feature

Question

I have recently found an interesting behavior of C# compiler. Imagine an interface like this:

public interface ILogger
{
   void Info(string operation, string details = null);
   void Info(string operation, object details = null);
}

Now if we do

logger.Info("Create")

The compiler will complain that he does not know which overload to chose (Ambiguous invocation...). Seems logical, but when you try to do this:

logger.Info("Create", null)

It will suddenly have no troubles figuring out that null is a string. Moreover it seems that the behavior of finding the right overload has changed with time and I had found a bug in an old code that worked before and stopped working because compiler decided to use another overload.

So I am really wondering why does C# not generate the same error in the second case as it does in the first. Seems very logical to do this, but instead it tries and resolves it to random overload.

P.S. I don't think that it's good to provide such ambiguous interfaces and do not recommend that, but legacy is legacy and has to be maintained :)

Answer 1

There was a breaking change introduced in C# 6 that made the overload resolution better. Here it is with the list of features:

Improved overload resolution

There are a number of small improvements to overload resolution, which will likely result in more things just working the way you’d expect them to. The improvements all relate to “betterness” – the way the compiler decides which of two overloads is better for a given argument.

One place where you might notice this (or rather stop noticing a problem!) is when choosing between overloads taking nullable value types. Another is when passing method groups (as opposed to lambdas) to overloads expecting delegates. The details aren’t worth expanding on here – just wanted to let you know!

---

but instead it tries and resolves it to random overload.

No, C# doesn't pick overloads randomly, that case is the ambiguous call error. C# picks the better method. Refer to section 7.5.3.2 Better function member in the C# specs:

7.5.3.2 Better function member

Otherwise, if MP has more specific parameter types than MQ, then MP is better than MQ. Let {R1, R2, …, RN} and {S1, S2, …, SN} represent the uninstantiated and unexpanded parameter types of MP and MQ. MP’s parameter types are more specific than MQ’s if, for each parameter, RX is not less specific than SX, and, for at least one parameter, RX is more specific than SX:

Given that string is more specific than object and there is an implicit cast between null and string, then the mystery is solved.