Some things are better left to the subconscious. Otherwise one might find themselves in a position of a centipede who lost the ability to walk as soon as it started wondering which leg to move first.
> C++’s classical OOP system supports “covariant return types,” but it does not support “contravariant parameter types.”
The problem in the authors "Animal doctor" example is that the universe of all possible animal types is practically unbounded, or "open".
What you want here are "open multimethods": something Bjarne Stroustrup has wanted in C++ for a long time[0] but have been implemented in library form[1].
Of course, the thing to remember is that, as soon as you go to an open multiple dispatch arrangement, you will lose much of the static safety guarantees that the type-system affords us. There will always be runtime/dynamic type checking, and a runtime failure case.
If you don't want an open system, then some combination of templates for static polymorphism and strategic type-erasure will get the job done. e.g. use boost::variant and multivisitation [2], and the compiler will instantiate all O(n^2) methods for you.
In OOP, isn't that essentially just overloading? In many OO languages, you could write both of those lines as-is (with corresponding method bodies) and have valid code. They'll typically be treated as two separate methods that just happen to have the same name.
No because multi-mthods don't have a self/this pointer as such, rather they are dispatched at runtime taking into account the actual types of each parameter.
The example is just that, an example. There's no logical reason to not have contravariant parameter types - they follow directly from the Liskov substitution principle.
The reason why C++ doesn't have them is because they are relatively harder and more costly to implement than return types (consider that multiple inheritance means that pointer-to-derived often needs to be offset to be used as pointer-to-base).
This seems pretty unrelated to the idea of covariant and contravariant four-vectors in relativity and electromagnetism. I wonder if there's some clever and insightful connection, or if it's more that the words just mean "varies together" and "varies oppositely".
> C++’s classical OOP system supports “covariant return types,” but it does not support “contravariant parameter types.”
Interestingly enough, std::function correctly supports contravariant parameters; it also correctly handles co/contra variance correctly via smart pointers (as long as the smart pointers support it themselves of course).
Is the “obvious” behavior mentioned in the article what the standard specifies? Because it’s surprising to me that the compilers are so broken in these cases…
