views:

158

answers:

3

Is this a limitation of the CLR or are there compatibility concerns with existing code?

Is this related to the messed up variance of delegate combining in C# 4.0?

Edit: Would it be possible to have a language using co-/contravariance without that limitation running on the CLR?

+8  A: 

You are going to want to read Eric Lippert's post on why it works the way it does. The short of it is that they allowed as much variance as possible without allowing developers to make bad mistakes in programming that could cause difficult to track down errors. The amount of variance in 4.0 is greatly expanded over the 3.0 rules, and from what I understand it was a balance between what is benificial to the developer and what is safe to allow without causing too much of a headache through unintentional mistakes.

http://blogs.msdn.com/b/ericlippert/archive/tags/covariance+and+contravariance/default.aspx

Kevin
Although I can understand the concerns about the usability, Java had this for ages with very little problems. I could imagine that this restrictions creates more complex, problematic workarounds than it simplifies things.
soc
thecoop
@thecoop: You were talking about the developers point of view in your answer, not about the technical difficulties on the implementation side. So the implemematation details of how variance is implemented on the JVM/CLR is not really a concern of the developer.
soc
+4  A: 

Simple answer: it's a CLR limitation.

(I haven't seen a good, concrete explanation for this anywhere... I don't remember seeing one in Eric's blog series about it, although I may well have missed it somewhere.)

One thing I would say is that both delegates and interfaces already form "layers of indirection" over the real types; views on methods or classes, if you will. Changing from one view to another view is fairly reasonable. The actual class feels like a more concrete representation to me - and shifting from one concrete representation to another feels less reasonable. This is a very touchy-feely explanation rather than a genuine technical limitation though.

Jon Skeet
That sounds pretty bad.So basically Microsoft repeats the mistake that Sun did with Generics?Or is it planned to lift this restrictions in a future update to the CLR?
soc
The implementation is not a 'mistake' - it was an explicit design decision they thought about, and they have reasons for implementing it the way they did.
thecoop
@soc: It's *nothing* like Sun's mistakes with generics. Whether they might allow it in a future release is anyone's guess.
Jon Skeet
@thecoop: I don't want to argue that they didn't compare all technical feasible solutions and chose the one they thought was the best.But this is _exactly_ the reasoning Sun gave us when people asked why they didn't do the generics right.I can already smell that this decision will be a PITA in a few years.
soc
@Jon Skeet: Interesting. What could make Oracle consider adding JVM support, seeing that they are struggling to even get closures/SAM/"defender" methods/extension methods/tail calls right?
soc
@soc: What could make Oracle consider adding JVM support for what, exactly?
Jon Skeet
@Jon Skeet: Sorry, my mistake. I meant support for generics in the JVM/.class files.
soc
@soc: So what's commonly known as "reified generics"? I have no idea whether that will happen.
Jon Skeet
@Jon Skeet: Exactly :-) I'm just frustrated that there is no mainstream VM out there which supports even _some_ of the common concepts of the last decades. It's sad to see how much is done in academia vs. how much gets delivered to developers due to all kinds of constraints (time, money, compatibilty, marketing, etc.) ...
soc
... But as far as I understand doing generics _right_ will require non-compatible changes to the JVM and the classfile format. That's nothing Oracle is willing to do. Although some things could be done via different classloaders/bytecode converters, some abominations like raw types vs. parameterized types will create hard to solve problems. It will be interesting if a third party will step forward and forks the whole Java infrastructure ...
soc
+2  A: 

It is a CLR limitation. See http://stackoverflow.com/questions/2541467/why-does-c-4-0-not-allow-co-and-contravariance-in-generic-class-types for additional commentary.

kvb