A recent Stack Overflow question piqued my interest. It looked like some inappropriate methods were being considered in overload resolution, when I thought they should have been rejected earlier. Yet again, I thought I’d found a compiler bug, but it turned out to be a case of misreading the spec. I’m arrogant enough to think that if I misread the spec, someone else might too, so I thought I’d dig into it a bit.

It turns out that Eric Lippert has written about the same area of the spec, but in the more complicated scenario where type inference is involved – in other words, where the compiler is working out what generic type arguments should be supplied to a method. While that’s certainly interesting, type inference introduces a whole extra bit of the spec which I prefer to avoid for reasons of health. We can still explore the same key process without involving type inference. I’m effectively revisiting one small part of Eric’s blog post – as much to make sure that I understand it as much as anything else.

The relevant area of the C# 4 spec is section 7.6.5.1, "Method invocations". Broadly speaking, this defines the process for choosing which method to invoke as:

1. Find a set of candidate methods
2. Remove methods which aren’t in the most derived type. This is one of the strange areas of overloading which can easily cause surprise. I’ve talked about it elsewhere, particularly in my article on overloading.
3. If we haven’t found anything else, resort to extension methods
4. Pick the best method out of the set
5. Validate that the best method is actually sane

Let’s look at this in three different contexts.

Example 1: Ambiguity

Now, for the purposes of this post I’m only interested in where generic type parameter constraints are checked, and the effects of that on the overall process. Let’s look at a concrete example:

Okay, so we’ve got two methods called M with different constraints. I’ve given them both parameters of different reference types. Without the parameters, we couldn’t even declare the two methods, as they would have the same signature: the declarations only differ in generic constraints, and constraints aren’t part of the signature. Both parameter types are reference types, so the argument we’re passing (null) is valid for both parameters.

So, what happens when we try to call Foo<object>(null)? Intuitively we might expect it to call the second overload, with the Exception parameter – because that has a constraint on T which is satisfied by the type argument, whereas the first overload has a value type constraint on T, which clearly isn’t satisfied by object. But what happens in the spec?

Well, as per the list above, we first need to find the set of candidate methods. This is where I got confused. Working out the method group is easy – both methods are in it. We’ve supplied type arguments, and both methods are generic, so this bit of the spec applies:

If F is generic and M includes a type argument list, F is a candidate when:

• F has the same number of method type parameters as were supplied in the type argument list, and
• Once the type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of F satisfy their constraints (§4.4.4), and the parameter list of F is applicable with respect to A (§7.5.3.1).

Note that here, "F" is the method under consideration, and "M" is the invocation expression.

The first bullet is fine: we have a single type argument, and both methods have a single type parameter. So what about the second? It talks about types satisfying constraints, so at first glance you might expect this to rule out the first overload. That’s certainly what I thought initially. But look carefully… it’s talking about the types in the parameter list – checking that they satisfy their constraints. It’s not talking about the type arguments for the method itself, or the constraints there.

Now our two parameters (string and Exception) are both nongeneric, so they can’t even have constraints. Both end up being candidate methods, and because neither is better than the other with respect to our invocation, the call ends up being ambiguous:

Test.cs(13,9): error CS0121: The call is ambiguous between the following methods or properties: ‘Test.Foo<object>(string)’ and ‘Test.Foo<object>(System.Exception)’

The next obvious question is what situation the constraint checking here does have an effect. Let’s look at a very slightly different example.

Example 2: Weeding out invalid constructed parameter types

This time I’m going to introduce an extra generic type. It’s called Factory, and TItem is constrained to have a parameterless constructor. I’ve called it TItem rather than just T for the sake of clarity later on. We’re not going to give it any behaviour, as we’re just interested in the type declaration. Here’s the complete code for the example:

Now, the first thing to note is that just to declare the first method with a parameter of Factory<T>, we have to ensure that T will have a parameterless constructor. That’s coverted by the constraint of T : struct, fortunately.

Now let’s look at the method invocation. This time we’re trying to use string as the type argument. The second method is obviously a candidate – it’s fine in every way. But what about the first?

After type argument substitution, the parameter list for the first method looks like this:

Now the spec says that each type in the parameter list has to be valid with respect to its constraints. In this case, it isn’t: string doesn’t have a parameterless constructor, so the type Factory<string> is invalid.

So, the first method is rejected, the second is fine, so it compiles with no problems. The important thing to note is that the compiler hasn’t taken any notice of the where T : struct part of the first method’s declaration… it’s only rejecting the first method on the basis of the constraint on Factory<T>. We can demonstrate that by changing the method invocation:

Now object does have a parameterless constructor, so the method is still part of the candidate set, and we’re back to the same ambiguous position of our first example.

Now we haven’t yet managed to trip the compiler up on the final part of our list – validating the constraints of method after it’s been chosen.

Example 3: Final validation

I could demonstrate this with a single method, so that overload resolution had no choices to make. However, we’ll have a little bit more fun. Here’s our final sample code:

Gone is Factory<T> – we’re back to simple parameters. The big difference between this example and the first one, however, is that the parameters are object and string instead of string and Exception. That means that although both methods are in the candidate set, the second one is deemed "better" than the first because the conversion from null to string is better (more specific) than the conversion from null to object.

So, the compiler resolves everything about the method invocation without paying any attention to the generic constraints involved until the very last moment – where it notices that the chosen method (the second one) isn’t valid when T is int, and fails with this error:

Test.cs(13,9): error CS0452: The type ‘int’ must be a reference type in order to use it as parameter ‘T’ in the generic type or method ‘Test.Foo<T>(string)’

There’s no mention of ambiguity, because by this point there isn’t any ambiguity. The cruel irony is that if only the compiler had applied the constraints earlier, it would have found that calling the first method is perfectly valid in every way.

Conclusion

I’m not going to try to argue the pros and cons of the way the language has been designed – Eric has some thoughts on that in the blog post, and obviously he has much more insight into the design process than I do. However, next time you find yourself trying to understand why the compiler is behaving in a particular way, hopefully one of these examples may help you.