Covariance and Contravariance in C#, Part Two: Array Covariance

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Cline — Tue, 18 Sep 2012 23:54:01 GMT

Personally I love array covariance, and wish generic lists were covariant. IEnumerables would be syntactically more tolerable if they were addressable like lists. In other words if you don't want array covariance, a dedicated IReadableList might have been worthwhile.

Covariance and Contravariance in C#, Part Four: Real Delegate Variance

Fabulous Adventures In Coding — Tue, 19 May 2009 22:57:37 GMT

In the last two posts I discussed the two kinds of variance that C# already has -- array covariance and

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

Journal of Abu Sayed Mohammad Ismail — Thu, 18 Dec 2008 16:24:39 GMT

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

Community Convergence XXXIV

Charlie Calvert's Community Blog — Mon, 29 Oct 2007 08:38:38 GMT

Welcome to the Thirty-Fourth issue of Community Convergence. This is a time when the team is in transition.

Community Convergence XXXIV

Charlie Calvert's Community Blog — Mon, 29 Oct 2007 08:35:24 GMT

Welcome to the Thirty-Fourth issue of Community Convergence. This is a time when the team is in transition.

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Grant — Thu, 18 Oct 2007 19:35:06 GMT

To elaborate on my original example, should the following code throw a compile-time error, a run-time error, or do copy-on-write? I really am curious to see what you think the right way is. I've been goofing around a lot with algebraic data types lately and contemplating the differences between ADTs and objects, and when each is appropriate. So far, the practical rule of thumb I've come up with is: If you find yourself doing RTTI, that object hierarchy should've been represented with ADTs.

Giraffe[] giraffes = new Giraffe[10];

...

// somewhere else

Animal[] animals = giraffes;

...

amimals.append(new Turtle()); /* not sure if it's really valid C#, but you get the point */

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Eric Lippert — Thu, 18 Oct 2007 18:41:01 GMT

A good question.

In this case the covariance is perfectly safe because you are treating arrays as read-only for the purposes of this method. It's only when you try to write to the array that you have a potential problem, and you don't do that here.

The way to get safe covariance is to separate out the read-only operations into interfaces and make them covaraint. If you wrote your program to take two IEnumerable<object> objects and we could somehow make IEnumerable<T> covariant in T then that would be perfectly type safe. IEnumerable does not allow you to write to the object, only read from it, so it is safe for covariance. You could then pass your IEnumerable<Giraffe> and IEnumerable<Animal> to the function and it would be just fine.

Of course, I have just spoiled the surprise; that is precisely where this series of posts is heading.

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Gabe — Thu, 18 Oct 2007 18:30:07 GMT

Without the type of covariance as implemented in C#, how would I write a function like this:

static bool ArrayEquals(object[] a, object[] b)

{

;;if (a.Length != b.Length) return false;

;;for (int i = 0; i < a.Length; i++) if (!a[i].Equals(b[i]) return false;

;;return true;

}

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Eric Lippert — Thu, 18 Oct 2007 01:38:15 GMT

I agree with you that this situation is extremely irksome. However, it is one that we are stuck with.

However, it _is_ covariance. I have a partial ordering on types (CLR assignment compatibility) and an operator from type to type ("make an array type") which preserves the ordering. That's the _definition_ of "covariant operator".

Perhaps you prefer "always-typesafe liskov-style substitution" as the basis for a partial ordering, rather than the sometimes-not-typesafe ordering that I've chosen. If that's your choice of partial ordering, then I agree with you, making arrays is not covariant. But that's not the partial ordering I'm choosing for the purposes of this series of articles.

You theory guys seem bound and determined to reject my choice of partial ordering today. That is your right, of course, but since I'm the guy who is going to have to implement this in a compiler that targets the CLR, choosing "assignment compatible in the CLR" is a highly pragmatic choice for me.

re: Covariance and Contravariance in C#, Part Two: Array Covariance

Adam — Thu, 18 Oct 2007 00:10:04 GMT

This is not actually covariance.

The type of consumers that can accept Giraffes is "smaller" than the type of consumers that can accept Animals: if a consumer can accept an Animal, then it can accept a Giraffe, but not vice versa.

For example, the type of write-only arrays of Giraffes should be a subtype of the type of write-only arrays of Animals.

The type of producers that can make Giraffes is "larger" than the type of producers that can make Animals: if a producer can make Giraffes, then it can make Animals.

For example, the type of read-only arrays of Animals should be a subtype of the type of read-only arrays of Giraffes.

Since an array can both produce (e.g. animals[0]) and consume (e.g. animals[0]=myanimal), Animal[] should be neither a subtype nor a supertype of Giraffe[].

So to address the question of how the following should be handled:

Giraffe[] giraffes = new Giraffe[10];

I say it should be handled with a compile-time error.