No warning or error (or runtime failure) when cont

Question

First, remember that a .NET String is both IConvertible and ICloneable.

Now, consider the following quite simple code:

//contravariance "in"
interface ICanEat<in T> where T : class
{
  void Eat(T food);
}

class HungryWolf : ICanEat<ICloneable>, ICanEat<IConvertible>
{
  public void Eat(IConvertible convertibleFood)
  {
    Console.WriteLine("This wolf ate your CONVERTIBLE object!");
  }

  public void Eat(ICloneable cloneableFood)
  {
    Console.WriteLine("This wolf ate your CLONEABLE object!");
  }
}

Then try the following (inside some method):

ICanEat<string> wolf = new HungryWolf();
wolf.Eat("sheep");

When one compiles this, one gets no compiler error or warning. When running it, it looks like the method called depends on the order of the interface list in my class declaration for HungryWolf. (Try swapping the two interfaces in the comma (,) separated list.)

The question is simple: Shouldn't this give a compile-time warning (or throw at run-time)?

I'm probably not the first one to come up with code like this. I used contravariance of the interface, but you can make an entirely analogous example with covarainace of the interface. And in fact Mr Lippert did just that a long time ago. In the comments in his blog, almost everyone agrees that it should be an error. Yet they allow this silently. Why?

---

Extended question:

Above we exploited that a String is both Iconvertible (interface) and ICloneable (interface). Neither of these two interfaces derives from the other.

Now here's an example with base classes that is, in a sense, a bit worse.

Remember that a StackOverflowException is both a SystemException (direct base class) and an Exception (base class of base class). Then (if ICanEat<> is like before):

class Wolf2 : ICanEat<Exception>, ICanEat<SystemException>  // also try reversing the interface order here
{
  public void Eat(SystemException systemExceptionFood)
  {
    Console.WriteLine("This wolf ate your SYSTEM EXCEPTION object!");
  }

  public void Eat(Exception exceptionFood)
  {
    Console.WriteLine("This wolf ate your EXCEPTION object!");
  }
}

Test it with:

static void Main()
{
  var w2 = new Wolf2();
  w2.Eat(new StackOverflowException());          // OK, one overload is more "specific" than the other

  ICanEat<StackOverflowException> w2Soe = w2;    // Contravariance
  w2Soe.Eat(new StackOverflowException());       // Depends on interface order in Wolf2
}

Still no warning, error or exception. Still depends on interface list order in class declaration. But the reason why I think it's worse is that this time someone might think that overload resolution would always pick SystemException because it's more specific than just Exception.

---

Status before the bounty was opened: Three answers from two users.

Status on the last day of the bounty: Still no new answers received. If no answers show up, I shall have to award the bounty to Moslem Ben Dhaou.

Answer 1

I believe the compiler does the better thing in VB.NET with the warning, but I still don't think that is going far enough. Unfortunately, the "right thing" probably either requires disallowing something that is potentially useful(implementing the same interface with two covariant or contravariant generic type parameters) or introducing something new to the language.

As it stands, there is no place the compiler could assign an error right now other than the HungryWolf class. That is the point at which a class is claiming to know how to do something that could potentially be ambiguous. It is stating

I know how to eat an ICloneable, or anything implementing or inheriting from it, in a certain way.

And, I also know how to eat an IConvertible, or anything implementing or inheriting from it, in a certain way.

However, it never states what it should do if it receives on its plate something that is both an ICloneable and an IConvertible. This doesn't cause the compiler any grief if it is given an instance of HungryWolf, since it can say with certainty "Hey, I don't know what to do here!". But it will give the compiler grief when it is given the ICanEat<string> instance. The compiler has no idea what the actual type of the object in the variable is, only that it definitely does implement ICanEat<string>.

Unfortunately, when a HungryWolf is stored in that variable, it ambiguously implements that exact same interface twice. So surely, we cannot throw an error trying to call ICanEat<string>.Eat(string), as that method exists and would be perfectly valid for many other objects which could be placed into the ICanEat<string> variable (batwad already mentioned this in one of his answers).

Further, although the compiler could complain that the assignment of a HungryWolf object to an ICanEat<string> variable is ambiguous, it cannot prevent it from happening in two steps. A HungryWolf can be assigned to an ICanEat<IConvertible> variable, which could be passed around into other methods and eventually assigned into an ICanEat<string> variable. Both of these are perfectly legal assignments and it would be impossible for the compiler to complain about either one.

Thus, option one is to disallow the HungryWolf class from implementing both ICanEat<IConvertible> and ICanEat<ICloneable> when ICanEat's generic type parameter is contravariant, since these two interfaces could unify. However, this removes the ability to code something useful with no alternative workaround.

Option two, unfortunately, would require a change to the compiler, both the IL and the CLR. It would allow the HungryWolf class to implement both interfaces, but it would also require the implementation of the interface ICanEat<IConvertible & ICloneable> interface, where the generic type parameter implements both interfaces. This likely is not the best syntax(what does the signature of this Eat(T) method look like, Eat(IConvertible & ICloneable food)?). Likely, a better solution would be to an auto-generated generic type upon the implementing class so that the class definition would be something like:

class HungryWolf:
    ICanEat<ICloneable>, 
    ICanEat<IConvertible>, 
    ICanEat<TGenerated_ICloneable_IConvertible>
        where TGenerated_ICloneable_IConvertible: IConvertible, ICloneable {
    // implementation
}

The IL would then have to changed, to be able to allow interface implementation types to be constructed just like generic classes for a callvirt instruction:

.class auto ansi nested private beforefieldinit HungryWolf 
    extends 
        [mscorlib]System.Object
    implements 
        class NamespaceOfApp.Program/ICanEat`1<class [mscorlib]System.ICloneable>,
        class NamespaceOfApp.Program/ICanEat`1<class [mscorlib]System.IConvertible>,
        class NamespaceOfApp.Program/ICanEat`1<class ([mscorlib]System.IConvertible, [mscorlib]System.ICloneable>)!TGenerated_ICloneable_IConvertible>

The CLR would then have to process callvirt instructions by constructing an interface implementation for HungryWolf with string as the generic type parameter for TGenerated_ICloneable_IConvertible, and checking to see if it matches better than the other interface implementations.

For covariance, all of this would be simpler, since the extra interfaces required to be implemented wouldn't have to be generic type parameters with constraints but simply the most derivative base type between the two other types, which is known at compile time.

If the same interface is implemented more than twice, then the number of extra interfaces required to be implemented grows exponentially, but this would be the cost of the flexibility and type-safety of implementing multiple contravariant(or covariant) on a single class.

I doubt this will make it into the framework, but it would be my preferred solution, especially since the new language complexity would always be self-contained to the class which wishes to do what is currently dangerous.

---

edit:
Thanks Jeppe for reminding me that covariance is no simpler than contravariance, due to the fact that common interfaces must also be taken into account. In the case of string and char[], the set of greatest commonalities would be {object, ICloneable, IEnumerable<char>} (IEnumerable is covered by IEnumerable<char>).

However, this would require a new syntax for the interface generic type parameter constraint, to indicate that the generic type parameter only needs to

• inherit from the specified class or a class implementing at least one of the specified interfaces
• implement at least one of the specified interfaces

Possibly something like:

interface ICanReturn<out T> where T: class {
}

class ReturnStringsOrCharArrays: 
    ICanReturn<string>, 
    ICanReturn<char[]>, 
    ICanReturn<TGenerated_String_ArrayOfChar>
        where TGenerated_String_ArrayOfChar: object|ICloneable|IEnumerable<char> {
}

The generic type parameter TGenerated_String_ArrayOfChar in this case(where one or more interfaces are common) always have to be treated as object, even though the common base class has already derived from object; because the common type may implement a common interface without inheriting from the common base class.

Answer 2

Here's one attempt at justification for the lack of warning or error that I just came up with, and I haven't even been drinking!

Abstract your code further, what is the intention?

ICanEat<string> beast = SomeFactory.CreateRavenousBeast();
beast.Eat("sheep");

You are feeding something. How the beast actually eats it up to the beast. If it was given soup, it might decide to use a spoon. It might use a knife and fork to eat the sheep. It might rip it to shreds with its teeth. But the point is as a caller of this class we don't care how it eats, we just want it to be fed.

Ultimately it is up to the beast to decide how to eat what it is given. If the beast decides it can eat an ICloneable and an IConvertible then it's up to the beast to figure out how to handle both cases. Why should the gamekeeper care how the animals eat their meals?

If it did cause a compile-time error you make implementing a new interface being a breaking change. For example, if you ship HungryWolf as ICanEat<ICloneable> and then months later add ICanEat<IConvertible> you break every place where it was used with a type that implements both interfaces.

And it cuts both ways. If the generic argument only implements ICloneable it would work quite happily with the wolf. Tests pass, ship that, thank you very much Mr. Wolf. Next year you add IConvertible support to your type and BANG! Not that helpful an error, really.

Answer 3

Another explanation: there is no ambiguity, therefore there is no compiler warning.

Bear with me.

ICanEat<string> wolf = new HungryWolf();
wolf.Eat("sheep");

There is no error because ICanEat<T> only contains one method called Eat with those parameters. But say this instead and you do get an error:

HungryWolf wolf = new HungryWolf();
wolf.Eat("sheep");

HungryWolf is ambiguous, not ICanEat<T>. In expecting a compiler error you are asking the compiler to look at the value of the variable at the point at which Eat is called and work out if it is ambiguous, which it not necessarily something that can it can deduce. Consider a class UnambiguousCow which only implements ICanEat<string>.

ICanEat<string> beast;

if (somethingUnpredictable)
    beast = new HungryWolf();
else
    beast = new UnambiguousCow();

beast.Eat("dinner");

Where and how would you expect a compiler error to be raised?

Answer 4

A compiler error could not be generated in such case because the code is correct and it should run fine with all types that does not inherit from both internal types at the same time. The issue is the same if you inherit from a class and an interface at the same time. (i.e. use base object class in your code).

For some reason VB.Net compiler will throw a warning in such case similar to

Interface 'ICustom(Of Foo)' is ambiguous with another implemented interface 'ICustom(Of Boo)' due to the 'In' and 'Out' parameters in 'Interface ICustom(Of In T)'

I agree that the C# compiler should throw a similar warning as well. Check this Stack Overflow question. Mr Lippert confirmed that the runtime will pick one and that this kind of programming should be avoided.