Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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

It is a CLR limitation. See Why does C# (4.0) not allow co- and contravariance in generic class types? for additional commentary.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top