Covariance and Contravariance, Part Eleven: To infinity, but not beyond

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Frank Quednau — Wed, 07 May 2008 22:08:23 GMT

"expression is too complex to compile" is actually what my brain said, too. Indeed, the whole subject is fascinating and your posts on the issue are on the "toread" list.

For now, I just can't manage to assign null to a struct - a feat that Nullable<T> seems to be perfectly capable of. How can I implicitly convert a null to a struct? the closest I get gives me CS0553...sorry I ranted here, but it was bugging me and your post right from the compiler front hit me on my Feed :)

Thanks for your valuable and brain-crunching posts!

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Eric Lippert — Wed, 07 May 2008 23:05:59 GMT

Nullable<T> does not assign a null to a struct. Nullable<T> is nothing more nor less than simply a struct something like:

struct Nullable<T> where T : struct

{

readonly T t;

readonly bool hasValue;

... constructors, accessors, and so on

}

That's all folks. The rest is just compiler and runtime magic. The compiler turns "if (n == null)" into "if (n.HasValue == false)", turns "int n = null" into "n = new Nullable<int>();", etc.

Perhaps what you want to do is not "convert a null to a struct" but rather "get the default value for a struct"? In that case you can just say:

T t = default(T);

If T is numeric, default(T) is zero. If T is a reference type, default(T) is null. bool -- false. Nullable type -- nullable type with hasValue=false. struct -- struct with all its fields set to THEIR default types.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

David Nelson — Thu, 08 May 2008 00:13:29 GMT

My head is about to spin clean off my neck. "expression is too complex to compile" is a dramatic understatement.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Digitake — Thu, 08 May 2008 07:39:58 GMT

I think Church shows that this kind of the problem,i.e. to decide which expressions are equivalent, is an unsolvable problems.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Frank Quednau — Thu, 08 May 2008 13:06:26 GMT

Hi Eric,

thank you for your answers. I think I expressed myself too bland yesterday, I was more or less aware of the issues...

I was looking for a way as a .NET developer to get an analogous code statement to compile (In the wake of me having a lot of fun with the implicit operator). Anyway, most importantly for me was the info that the compiler does some magic, so there is no way to get the effect via developer-made .NET code. That's fine by me, but good to know.

Cheers and thanks :)

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Joren Vermijs — Fri, 09 May 2008 18:04:49 GMT

Is it not so that since double and string have no hierarchical relation, co- and contravariance are not relevant for determining A<double> -> B<string>, whatever A and B may be? Covariance preserves ordering, contravariance reverses ordering, but neither _creates_ ordering, as far as I see.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

configurator — Sun, 11 May 2008 12:25:16 GMT

Joren, it is in fact so, but that is not exactly the question at hand.

The question is not whether or not the cast is valid. The question is how to write the compiler to know that.

On the same note, think of as example for the halting problem (even though it is not equivalent, as Eric said):

write a program that can tell if the following method stops or not:

int thing(int x) { return thing(x + 1); }

Surely, both you and I can see that this method will never stop (disregarding the overflow exception). But for a computer program, it would not be that obvious.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Joren Vermijs — Sun, 11 May 2008 16:47:52 GMT

Re: The question is how to write the compiler to know whether or not the cast is valid.

Yes, I understand that. Eric said the problem is not solvable in general, so returning the error 'too complex to compile' is a fine approach.

But I thought: is it not at least possible to write a compiler that can follow the reasoning from the string-double relation (or other simple relations) to the interface relation, in stead of only trying to reduce the generic interface relation to a simple relation (which, as my previous post implied, can fail while the other method works)?

It seems that trying the problem A<X> -> B<Y> from both sides (both from the relation between X and Y, and the relation between A and B) will lead to more classes of cases that the compiler can handle without giving up.

Of course the question remains whether anything whose validity can't be ascertained from the relation between A and B alone will ever be practically useful. I'd say 'no' is most likely, but I've hardly investigated the problem any further.

VCS Team Links for May 22, 2008

Charlie Calvert's Community Blog — Thu, 22 May 2008 22:12:36 GMT

Rather than place the links to the most recent C# team content directly in Community Convergence , I

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

orangy — Thu, 19 Jun 2008 23:44:31 GMT

I wonder if some future CSC could allow implicit interface implementation in variant way?

Like this:

class MyPOD : IClonable

{

public MyPOD Clone() { ... } // this could implicitly implement IClonable.Clone

}

Eric, can such variance be specified on IClonable interface?

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Eric Lippert — Thu, 19 Jun 2008 23:50:59 GMT

That kind of variance is called "return type covariance". As I mentioned early on in this series, (a) this series is not about that kind of variance, and (b) we have no plans to implement that kind of variance in C#.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Konstantin Triger — Fri, 04 Jul 2008 00:07:59 GMT

Hello Eric,

After my last re-reading of your co[ntra]variance series, I believe I came to a new point.

After all there are only 3 possibilites:

1. Clear covariance (IEnumerator<T>).

2. Clear contravariance (IComparer<T>).

3. Undecidable (IList<T>).

All the 3 possibility are easily detectable by compiler and I believe for the first two we would like the compiler will decide the variance automatically. We need a solution for the third case only.

To see the solution, I would like first analyze how we selected which case the given interface belongs to. We analyzed the method signatures in which T is involved:

1. If in all of them T is 'out' parameter, the interface is covariant.

2. If in all of them T is 'in' parameter, the interface is contravariant.

3. If there is a mix - undecidable.

My solution is to say the compiler how I'm going to use my variable and enable either covariant or contravariant invocations:

IList<Animal> aa = whatever;

IList<in Giraffe> ag = aa;

IList<out Giraffe> agX = aa; //fails to compile

ag user sees: 'int ag.IndexOf(Giraffe)' and 'object ag[int]'.

IList<Giraffe> ag = whatever;

IList<out Animal> aa = ag;

IList<in Animal> aaX = ag; //fails to compile

aa user sees: 'int aa.IndexOf(<only null can be passed>)' and 'Animal aa[int]'.

Now I can say in a type safe manner:

class X<T> {

T _t;

void Test(IList<out T> at) {

T t = at[0]; //clearly t is 'out' parameter

}

void Test(IList<in T> at) { //overloaded method!

int i = at.IndexOf(_t); //clearly _t is 'in' parameter

}

...

new X<Animal>().Test(new List<Giraffe>()); //first method is called

new X<Giraffe>().Test(new List<Animal>()); //second method is called

Kosta

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Konstantin Triger — Tue, 08 Jul 2008 10:10:16 GMT

I found a very interesting presentation, which shows different options, pros and cons for the implementation: http://research.microsoft.com/~akenn/generics/ECOOP06.ppt.

It's clear that my approach is a variation on Java theme.

Interestingly enough that in order to create a covariant/contravariant projection in C#, currently one will need to define a special read/write interface. While this is somehow acceptable with one parameter, what is suggested if I have 2 or more, i.e.:

MyClass<T1,T2,T3>{}

To cover all the possibilities I need to define 2^3 interfaces. Yes, may be some of them are not useful, but I easily may fail into a situation where I need declare 4-5 interfaces. How is it addressed?

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

John "Z-Bo" Zabroski — Sun, 13 Jul 2008 20:33:37 GMT

does this cover situations like ObservableCollection<T1<T2>> ?

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

David Piepgrass — Sun, 27 Jul 2008 01:18:41 GMT

I'm curious, on what basis does the CLR decide that

public interface IN<in U> {}

public interface IC<X> : IN<IN<IC<IC<X>>>> {}

is illegal, and does it become legal if U is made invariant?

OT: why the heck isn't return type covariance on the table? In terms of usefulness, it's in the same ballpark as variance in generics but a vastly simpler concept and dead easy to implement (except for compatibility issues). I've wanted return type covariance for years :(

Object Oriented F# - Extension Everything

Matthew Podwysocki's Blog — Wed, 10 Sep 2008 01:27:42 GMT

A post by Jeremy Miller caught my eye this morning in regards to extension methods in Javascript . While

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Avi Farah — Sat, 11 Oct 2008 23:10:34 GMT

Eric,

your blog is fabulous. I may be too late for the next version of C#. So far Covariance/Contravariance seems to encompas type parameters. If possible expand the scope of Covariance/Contravariance to include delegates.

--Avi

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Rajesh Kumar. — Mon, 20 Oct 2008 09:30:10 GMT

One thing i miss from C# is the C++ TypeDef statement.

That would make the whole thing a bit more readable!, without causing 'expression too complex to parse' in my brain.

re: Covariance and Contravariance, Part Eleven: To infinity, but not beyond

Tim Foley — Fri, 14 Nov 2008 23:34:26 GMT

On the subject of return-type covariance, it initially seemd to me like you can try to get the benefit of such a feature for a specific case, like cloning, as follows:

// covariant interface for cloning:

interface IClonable<+T> { T clone(); }

// an example use case in a hypothetical compiler:

interface IExpression : IClonable<IExpression> {}

class Add : IExpression, IClonable<Add> { public Add clone(); }

The clone() method on class Add should be able to satisfy both the IClonable<Expression> and IClonable<Add> interfaces. Clients can clone an arbitrary expression, but if they have something statically known to be an Add then they know that cloning will return another Add.

Looking at that case, though, it is clearly similar to the case in a previous blog post here that was almost universally agreed to be a compile-time error. The Add class has two different variations of IClonable in its inheritance hierarchy.

You could claim that Add isn't a problem, since it satisfies the two interfaces with an identical implementation, so casting an Add to an IClonable<object> wouldn't be ambiguous. But what if there had been an Expression base class (instead of an IExpression interface) which supplied a default implementation for IClonable<Expression>.

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

Journal of Abu Sayed Mohammad Ismail — Thu, 18 Dec 2008 16:22:53 GMT

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