You may want to look at this blog, he does a fantastic job of explaining it, but I think it will take more examples to clear it up for people, as this gets into a very hard-to-understand area, but, the quote below from the article sums it up well. http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html “covariance and contravariance” means that … Read more
The answer given (that there is no variance involving value types) is correct. The reason covariance and contravariance do not work when one of the varying type arguments is a value type is as follows. Suppose it did work and show how things go horribly wrong: Func<int> f1 = ()=>123; Func<object> f2 = f1; // … Read more
This is a fundamental feature of object-oriented programming that doesn’t get as much attention as it deserves. Suppose you have a collection C[+T]. What the +T means is that if U <: T, then C[U] <: C[T]. Fair enough. But what does it mean to be a subclass? It means that every method should work … Read more
Covariance is pretty simple and best thought of from the perspective of some collection class List. We can parameterize the List class with some type parameter T. That is, our list contains elements of type T for some T. List would be covariant if S is a subtype of T iff List[S] is a subtype … Read more
Here’s a relevant excerpt from Java Generics and Collections: 2.4. The Get and Put Principle It may be good practice to insert wildcards whenever possible, but how do you decide which wildcard to use? Where should you use extends, where should you use super, and where is it inappropriate to use a wildcard at all? … Read more
First off, as Tomas says, it is not supported in the CLR. Second, how would that work? Suppose you have class C<out T> { … how are you planning on using T in here? … } T can only be used in output positions. As you note, the class cannot have any field of type … Read more
Consider what would happen if the compiler allowed that: interface IR<out T> { void D(T t); } class C : IR<Mammal> { public void D(Mammal m) { m.GrowHair(); } } … IR<Animal> x = new C(); // legal because T is covariant and Mammal is convertible to Animal x.D(new Fish()); // legal because IR<Animal>.D takes … Read more
It’s not safe at compile time. In other words, there’s code which is legal by the language rules, but fails at execution time, without any explicit casting to give a big warning sign of “this might fail”. The CLR makes sure that only valid writes succeed at execution time. For example: string[] strings = new … Read more
Because that’s called overloading. In particular, the return type type can be covariant because it is not considered when overloading, and it therefore still matches the superclass or interface’s implementation. Parameters are considered when overloading. You very well might have an optimization with Number doSomethingWithNumber(Integer value) compared to Number doSomethingWithNumber(Number value).
Update: Ooops. As it turned out, I mixed up variance and “assignment compatibility” in my initial answer. Edited the answer accordingly. Also I wrote a blog post that I hope should answer such questions better: Covariance and Contravariance FAQ Answer: I guess the answer to your first question is that you don’t have contravariance in … Read more