contravariant argument types: wanna?

Jeremie Pelletier jeremiep at gmail.com
Tue Sep 22 17:49:59 PDT 2009


Andrei Alexandrescu wrote:
> Hello,
> 
> 
> Today, overriding functions have covariant return types:
> 
> class A {
>     A clone();
> }
> 
> class B : A {
>     B clone(); // fine, overrides A.clone
> }
> 
> That is entirely principled and cool. Now the entire story is that 
> overriding function may have not only covariant return types, but also 
> contravariant argument types:
> 
> class A {
>     A fun(B);
> }
> 
> class B : A {
>     B fun(A); // fine (in theory), overrides A.fun
> }
> 
> Today D does not support contravariant arguments, but Walter told me 
> once he'd be quite willing to implement them. It is definitely the right 
> thing to do, but Walter would want to see a compelling example before 
> getting to work.
> 
> Is there interest in contravariant argument types? If so, do you know of 
> a killer example?
> 
> 
> Thanks,
> 
> Andrei

I can't think of an use for contravariant parameters, since a B is 
guaranteed to always be a A, I don't see the point of being able to 
declare fun(A).

However, I would love to hear about covariant parameters, it would be 
most useful for interface implementations:

interface A {
	A fun(A);
}
class B : A {
	B fun(B);
}
class C : A {
	C fun(C);
}

Currently you need some pretty boring boilerplate code, which isn't 
complicated but gets repetitive when you have hundreds of such cases:

class B : A {
	B fun(A) {
		if(B b = cast(B)b) // do stuff
		else throw Error("Invalid object type");
	}
}

Jeremie



More information about the Digitalmars-d mailing list