contravariant argument types: wanna?

[Andrei Alexandrescu]

Jeremie Pelletier wrote:
> 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).

The point is that B can state it is ok with a more general type than its 
base. This may be useful when you have a B instead of an A at your disposal.

> 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

This is what Eiffel does, and as your throw shows, is unsound. Covariant 
parameters is often mentioned when an explanation of Eiffel's demise is 
sought.


Andrei