Question

I have defined the following classes and methods:

 using System;
 using System.Linq.Expressions;
 using System.Windows.Forms;

 public class ReturnValue<T, S> {}

 public class Something<T>
 {
     // Sorry about the odd formatting. Trying to get it to fit nicely...
     public ReturnValue<T, C>
     Do<C, S>(C control, Expression<Func<C, S>> controlProperty)
     where C : Control
     {
         return new ReturnValue<T, C>();
     }

     public ReturnValue<T, ToolStripItem>
     Do<S>(ToolStripItem control, Expression<Func<ToolStripItem, S>> controlProperty)
     {
         return new ReturnValue<T, ToolStripItem>();
     }
 }

This compiles fine. Woo hoo! Half-way there. Then, I try to use it later with code like this:

 var toolStripItem = new ToolStripStatusLabel();

 var something = new Something<string>();
 something.Do(toolStripItem, t => t.Text); // Does not compile

This, however, dies with the following error message

The type ToolStripStatusLabel cannot be used as type parameter C in the generic type or method Something<T>.Do<C,S>(C, Expression<Func<C,S>>). There is no implicit reference conversion from ToolStripStatusLabel to Control.

It seems to me that the C# compiler has failed in this case though the two methods do not create a set of ambiguous method declarations. Control and ToolStripStatusLabel exist as siblings in the inheritance tree of Component. I would think that the compiler would have enough information to correctly bind the method invocation in the client code.

However, if I do the same thing with my own sibling classes, then everything compiles fine.

 public class Parent {}
 public class Child1 : Parent {}
 public class Child2 : Parent {}

 public class Something2<T>
 {
     public ReturnValue<T, C>
     Do<C, S>(C control, Expression<Func<C, S>> controlProperty)
     where C : Child1
     {
         return new ReturnValue<T, C>();
     }

     public ReturnValue<T, Child2>
     Do<S>(Child2 control, Expression<Func<Child2, S>> controlProperty)
     {
         return new ReturnValue<T, Child2>();
     }
 }

 var child2 = new Child2();
 var something2 = new Something2<string>();
 something2.Do(child2, c => c.GetType()); // Compiles just fine

Can anyone shed light on what I have done wrong, if anything?

Answer 1

The problem is that the first method is in the candidate set for overload resolution, because the type constraint C : Control is only applied after overload resolution has been performed. I believe you’re expecting it to be weeded out early – and it isn’t.

Now, if you treat C = ToolStripItem, the first overload is more specific than the second – so the result of overload resolution is to pick that first version.

The type constraint validation is then applied… and fails.

I have a blog post on this matter which may help you to understand the process, and then another blog post where I apply the rules in a rather silly way.

EDIT: In your second example, the type of the argument is exactly the type specified in the first parameter, so the first method doesn’t end up being more specific. The second method wins due to having fewer type parameters (I think; I haven’t checked it in detail) and is then validated and passes.

To put it back into ToolStripItem terms, you could actually make your first sample compile with one simple change:

// Change this
var toolStripItem = new ToolStripStatusLabel();
// To this...
ToolStripItem toolStripItem = new ToolStripStatusLabel();

Changing the compile-time type of toolStripItem from ToolStripStatusLabel to ToolStripItem takes away the “advantage” that the first method had, so it then compiles.