views:

185

answers:

4

Is it possible to "upcast" from a generic class based on T, into a generic class based on something more general than T?

For instance, say I have a class named Derived that inherits from a class named Base. Can I ever do something like this:

List<Derived> der = new List<Derived>();
List<Base> bas = (List<Base>) der;

Or, using interfaces, is it ever possible to do something like this:

List<MyClonableType> specific = new List<MyClonableType>();
List<IClonable> general = (List<IClonable>)specific;

As written here, each of these examples fails with an InvalidCastException. The question we're arguing about is whether it's actually impossible, or simply a syntax error that could be fixed if we knew how.

A: 

There is nice LINQ extension:

der.ToList<Base>();
Mendy
I believe this method creates a whole new collection. It can be useful, assuming you've got Linq, but it is not the same as a cast.
Auraseer
It is true that you can specifically deal with IEnumberable<T> types this way, but it isn't an actual cast as the question asks. In this case, the ToList<Base>() method creates a new list of <Base> and fills it by casting each item from the original.
Mike Schenk
If you're only going to *read* the list (which is the only case where the cast would make sense) presumably it does not matter whether you are reading a copy or the original.
finnw
finnw, it does matter. If I copy an object and save a reference to the copy, then the original gets changed by some other piece of code, I'll never know about the change. Also, just doing the conversion can be very costly, whereas a cast is pretty close to free.
Auraseer
+1  A: 

C# 4.0 will have that feature.

It will be enabled on interfaces and delegates which adhere to certain rules. List<T> won't be supported, as it is a concrete class. IList<T> also won't be supported, as its methods use T in both the in and out positions.

Bryan Watts
That link also tells me for sure that this cast is not allowed pre-4.0. That's exactly what I wanted to know.
Auraseer
Even in .NET 4.0 it will not apply to List<T>.
kvb
Good point. Variance is only supported on interfaces and delegates.
Bryan Watts
C# 4.0 will not have this feature for `List<T>`. It is inherently unsafe.
Jason
Nor will it have this feature on the interface `IList<T>`
Tinister
+1  A: 

This

List<Derived> der = new List<Derived>(); 
List<Base> bas = (List<Base>)der;

is not possible and should never be possible. What happens here:

Base b = new Base();
bas.Add(b);

Kaboom! is what happens. If the above were legal bas would just refer to der and der can not add instances of Base which is what the Add would be trying to do. (For concreteness, think of Base as Animal and Derived as Cat; you can not cast a List<Cat> to a List<Animal> because then you could add an instance of Dog to the casted list which would fail because it's really a List<Cat>.)

For similar reasons

List<MyClonableType> specific = new List<MyClonableType>();  
List<IClonable> general = (List<IClonable>)specific;  

should never be possible.

In C# 4.0 some of these issues will be solved with the notion of covariance and contravariance. For example, in C# 4.0 this will be legal:

List<Derived> der = new List<Derived>();
IEnumerable<Base> bas = der;

This is because IEnumerable<Base> only spits out instances of Base and since all Deriveds are Bases this is okay. Said another way, IEnumerable<Base> says "I know how to throw instances of Base at you" while List<Derived> says "I know how to throw instances of Derived at you." But as all Deriveds are Bases, this means that List<Derived> also knows how to throw instances of Base at you. Therefore, it should be able to be assigned to an instance of IEnumerable<Base>. This is what is possible in C# 4.0. This is an example of covariance.

I must stress that for types like List<T> which have methods that both eat Ts and spit out Ts it is not possible.

Jason
A: 

Two people apparently asked this question at the same time today. See my answer to this question:

http://stackoverflow.com/questions/2231668/c-polymorphism-simple-question

Eric Lippert