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
