Question

I’m targeting .NET 3.5. Let’s say I have a class, Bob, which is an abstract base class for SubBob.

I can declare this:

Bob b = new SubBob();

But I can’t do this:

 // compliation error - can't convert
BindingList<Bob> myList = new BindingList<SubBob>(); 

My guess is that BindingList doesn’t want you to do this because it has to know that the type that’s on the right hand side has the same memory layout as the left hand side. SubBob may have a larger size than a Bob.

Is there a way I can do the implicit conversion, or is a cast required?

Answer 1

The Short Answer

By instantiating BindingList<SubBob> you confine it to work with SubBob and more specific types (e.g. SubSubBob).

If you want Bob to fit there as well, declare myList as a list of the least specific type you want to support:

BindingList<Bob> myList = new BindingList<Bob>(); 

(or, more conveniently,)

var myList = new BindingList<Bob>(); 

Explanation

It is not about memory (BindingList would only hold a reference to the object, and all references are of the same size), rather it is about logical inconsistency you would introduce.

If such code was possible, you would be able to arbitrarily break type restrictions:

BindingList<Animal> myList = new BindingList<Cat>(); 
myList.Add(new Dog()); // bang!

myList is a list of Cats, how would you expect it to handle a Dog?

Compiler wouldn’t know there is a problem and would happily compile your code. What should happen when this code runs? An exception? But generics were introduced exactly to solve type safety problem.

A Side-Note on Co- and Contravariance

It’s correct that in .NET 4.0, generic covariance and contravariance were added for delegates and interfaces (not for classes). For example, IEnumerable<out T> is covariant that means you can assign it to variable of any type less derived than T:

IEnumerable<Cat> cats = new List<Cat> { new Cat("Hudson"), new Cat("Crookshanks") };
IEnumerable<Animal> animals = cats; // sequence of cats is sequence of animals

But this is only possible because IEnumerable<out T> guarantees it only returns T (keyword out) and never accepts it. If it accepted T as parameter, it would open the door to the problem described above. For this reason, ICollection is not covariant.

In a similar fashion, some interfaces guarantee they only accept T (keyword in) and never return it. Such interfaces are called contravariant and allow assignment to a variable with more specific T:

IComparer<Animal> animalComparer = // ...
IComparer<Dog> dogComparer = animalComparer; // comparer of animals is comparer of dogs