Justin Johansson 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
Yes please. Gimme, gimme, gimme. Andrei and Walter, you guys are legends.
Currently I'm developing a specialized collection library based on templated
quantified types. Such library is useful in pattern matching applications.
Now despite any (negative) comments I may have made on prior occasion regarding
Scala being too academic re covariance & contravariance, it is difficult
producing this type of library without language support for covariant and
contravariant typing.
Designing such support into D would bring even more credibility to the language
.. especially if you guys can come up with a neat syntax to effect this
feature. I'm impressed with the way Walter observed that the ! operator was
not a binary operator in C/C++ and then went about re-purposing it for template
syntax. Accordingly I wouldn't be surprised if you guys pulled another cool
rabbit-out-of-the-hat trick.
So yes there is extreme interest in my neck of the woods but as for a killer
example, I need to think this out in more time than this reply makes for at the
moment.
If you do this, I suspect that it will be the end of my D1 adventures and force
me into D2.
Cheers
Justin Johansson
Thanks. To paraphrase Mark Twain, the reports of Walter and I being
legend are greatly exaggerated.
Syntactically there is no need to change anything, just carry the change
in the implementation.
Andrei
