3

Possible Duplicate:
Why isn’t there generic variance for classes in C# 4.0?

As a rookie programmer I have a couple of questions about variance in .NET 4. Not so much about how it works, but why certain things are not variant and if other people would find this useful.

Question 1:

I know that interfaces and delegates can be covariant/contravariant in .NET 4, but why not classes? So, question 1:

List(of BaseClass) = List(of DerivedClass)

Is this somehow unsafe? Wouldn't this be useful?

Question 2:

Question 2 follows from question 1, but may deal more with signatures than variance. Suppose I have a MustInherit class with a MustOverride member:

Public MustInherit Class TestBase
    Public MustOverride Property SomeClass as BaseClass
End Class

In the derived class, why can't I override SomeClass and return a Derived Class Of BaseClass? Is this unsafe? Is it just that the signatures don't check for inheritance relationships?

Public Class TestSpecific
    Inherits TestBase
    Public Overrides Property SomeClass as DerivedClass
End Class

Any insight as to why this isn't allowed in .NET 4 would be appreciated.

Community
  • 1
  • 1
Casey Wilkins
  • 2,555
  • 2
  • 23
  • 31
  • To answer your second question (since the question was closed while I was answering): You can do this by adding a bit of generics to the base class. Java Enums use this, for example, to make sure `compareTo` can only be passed values of that enum. See [here](http://madbean.com/2004/mb2004-3/) and [here](http://msmvps.com/blogs/jon_skeet/archive/2008/08/20/lessons-learned-from-protocol-buffers-part-2-self-referential-generic-types.aspx). – BlueRaja - Danny Pflughoeft May 27 '10 at 14:58

1 Answers1

4

Eric Lippert answers the first part of you question here.

As for the second part of you question, return type covariance has been requested for both C# and VB.NET - however it has not yet been prioritized high-enough relative to other language features to make it into any release. If I remember correctly, this feature would also require changes to the CLR to be implemented appropriately.

As to why this is so, I'll channel Eric Lippert for a moment and respond that not implementing a feature is free, while implementing a features requires the budget and time to design, develop, test, and document it ... which is not free. A feature has to be sufficiently valuable to enough people to justify the expense of creating it.

Community
  • 1
  • 1
LBushkin
  • 129,300
  • 32
  • 216
  • 265
  • Thanks, read his post. I am confused as to why the generic parameter can't have any "writeable" fields/properties. Is there an example of how that would cause a problem? Going back to study his example further... – Casey Wilkins May 27 '10 at 14:50
  • 2
    Couldn't have said it better myself. :-) – Eric Lippert May 29 '10 at 04:22
  • 2
    @Casey: Suppose C is covariant in T and C has a method void M(T t). You have a variable x of type C. You convert a value of type C to C and assign it to x. Now you can call x.M(new Giraffe()) because as far as the compiler knows, M takes an object, not a Tiger. And then the runtime crashes when it tries to convert a giraffe to a tiger. That's why it's illegal for a covariant type to have a T that goes "in". – Eric Lippert May 29 '10 at 04:25