Covariance and Contravariance in C#, Part Six: Interface Variance

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Bryan Watts — Fri, 26 Oct 2007 20:33:31 GMT

Would the behavior surrounding variant types change based on the +/- modifier? Or does that just make it more explicit to the reader?

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Eric Lippert — Fri, 26 Oct 2007 20:50:02 GMT

The former. As I will discuss in my next post, we need a way to say "this is covariant, this is invariant", etc. We will not be able to deduce the desired variance just from the interface definition, so the default will still be "invariant".

Uh, hypothetically, of course.

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Bryan Watts — Fri, 26 Oct 2007 22:48:13 GMT

Is it a binary behavior, i.e. could we collapse it to a single token specifying "this is variant in the only way that makes sense here"? Hypothetically.

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Eric Lippert — Fri, 26 Oct 2007 23:40:04 GMT

An interesting idea -- however, as we'll see in my next post, the variance of one type parameter may depend upon the variance of another. There often is not one single "only way it makes sense here". There are often multiple ways that it could work, and we'd then have to choose.

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Stefan Wenig — Sat, 27 Oct 2007 12:18:24 GMT

I think one has to grasp the difference between covariance and contravariance to make any good use of it.

Guessing variance from the interface would be dangerous even if you could do it, because the interface might change later, and this should not hurt existing code by removing or changing variance. The developer of the interface has to make it clear that he wants variance, so he will also be aware that certain changes might not be possible later (or would be breaking).

During this blog series, I got used pretty well to the +/- notation, so why not. On the other hand, something more verbose like IEnumerable<covariant T> would not hurt either and be more c#-like. It's in declarations only anway.

Would this, hypothetically, be for interfaces only, or can we have it for generic reference types too?

This would be especially great because it would put an end to the "no common base type" problem of generics (well, not for value types), so instead of doing perverse reflection calls, we could just rely on

object x = new List<string>();

Assert (x is IEnumerable<object>)

(can't think of an example with classes right now, but I know I wanted it on several occations in the past)

(one could argue that another way to approach this problem would be to clean up the mess that generics made of the reflection API. probably not easy, but definately due!)

can't wait. what's the hypothetical timeline? ;-)

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Kyle Lahnakoski — Sat, 27 Oct 2007 17:32:44 GMT

Would it be wrong to just avoid the covariant and contravariant checks? With the complications you are showing, I think it is obvious that the parameter in a parametric type is orthogonal to the types of objects managed by that type.

The illusion of contravariant only appears when you ASSUME the domain you assign a method is the ONLY domain the method can act on. This assumption does not happen in all languages; a Javascript function can be designed to take a String, but can be passed any non-String. The output of such a method is well defined: it outputs an exception. With exceptions being accepted as part of a method's codomain, and realizing that all methods are well defined for all objects, then the issue of "contravariant on input parameters" disappears because all methods act on the same domain (everything).

I believe little is lost in terms of optimization.

Object[] o=new Object[];

String[] s=o; //Allowed at compile time

Assigning arrays, or any collection, can be checked at runtime when the contravariant relationship is broken. But this can be done at the collection level, not at the individual element level, as long as there is no type-erasure.

Same for function delegates; checks can be done at runtime. But I see no reason why simple constant propagation (constant TYPE propagation) would catch most illegal maneuvers at compile time anyway.

Furthermore, method inheritance must be contravariant on the parameter types to be logically consistent in an OO framework. And this works by delegating out-of-domain parameters back to the super class. I believe the logic in such a proof can be mimicked with some kind of recursive function delegate; proving "contravariant on parameter types" is logically inconsistent in a function delegate framework. But that is only a strong feeling.

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Stefan Wenig — Sat, 27 Oct 2007 21:28:16 GMT

Yeah, why bother with variance, haven't they heard of duck typing yet? Come on ... ;-)

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Ryan — Mon, 29 Oct 2007 05:48:01 GMT

I would love to have this kind of variance support.

All too often I need to drop down to the IL level to do this kind of work.

Thus, I am accustomed to the +- notation.

However, perhaps your next post will have compelling reasons for another notation.

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Kyle Lahnakoski — Mon, 29 Oct 2007 11:00:08 GMT

Stefan Wenig, I am not suggesting duck typing, I am suggesting strong dynamic typing of type parameters.

Correction: " Furthermore, method inheritance must be COVARIANT on the parameter types to be logically consistent in an OO framework."

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Stefan Wenig — Mon, 29 Oct 2007 11:46:02 GMT

Kyle,

in this case I don't understand what you're proposing. From your reference to JavaScript I just assumed you were talking about duck typing, which is the only way I know that can do this trick. If you're thinking about something else, is this anything that exists anywhere yet? Mind to post a link? Or is it a new idea you came up with? In this case, I'd ask you to elaborate.

Which types should be compatible at compile time? Base<anything> and Base<anything else>? Or even Base<anything> and Derived<anything else>? Or maybe even Sibling1<anything> and Sibling2<anything ese>, given they both derive from Base<T>?

How exactly does this translate to delegates? What do you mean by " Furthermore, method inheritance must be COVARIANT on the parameter types to be logically consistent in an OO framework."? The this parameter? any parameter? why?

Which kind of checks would have to be made at which point? Would you expect this to work for value type parameters too?

Sounds like this would hurt my brain even more than explicit co/contravariance, but maybe I'm just not getting it.

Stefan

re: Covariance and Contravariance in C#, Part Six: Interface Variance

Gilles Michard — Mon, 29 Oct 2007 16:44:40 GMT

To go back to a remark in one of the first posts:

What we strongly lack is overriding a read only property by a more specialized one.

More generically it would be convenient to define an overload of a method and to have some "OverrideAttribute(typeof(string))" to say e.g. string Compute(object o) is ovverriding the base class implementation of object Compute(string s).

In C# it could be expressed as the 'generic keyword' "override<string>".

Covariance on return types woul be a gift, and covariance of IEnumerable<T> would definitely ease our lifes.

After reading the CLR version 2 spec, and seeing covariance was not handled in Framework 2.0, I hoped it will be in 3.0. Then in 3.5. Try to make C# at least aware of what is specified in a delegate or interface, even if there is no language support to create it.

WAW!!! What a serie of blog posts for "Covariance and Contravariance" - C# Future...

Journal of Abu Sayed Mohammad Ismail — Wed, 24 Dec 2008 09:36:54 GMT

So nicely step by step blogged by Eric Lippert for "Covariance and Contravariance" as "Fabulous