Why are opEquals/opCmp arguments not in or const for Objects?

[Jonathan M Davis]

On Tuesday, March 19, 2013 02:17:28 Peter Williams wrote:
> Am I right in thinking that removal of these methods from Object
> will mean that it will no longer be necessary for the the
> argument to be of type Object and that the need for casting in
> the implementation will go away?

Well, IIRC, if when you override a function, and you give it a different 
parameter type, it's a new overload rather than actually overriding anything 
(even if the type of the parameter in the derived type's function is a derived 
type of the type of the parameter in the base class' function). So, if you 
don't use a common type for the parameter, you'll run into overload conflicts 
regardless. So, while you _could_ use something other than Object, you could 
run into overload conflicts if you do. That can be gotten around by aliasing 
base class functions into the scope of the derived class (though that may 
cause derived types to be compared as base types if they're referred to via 
references to the base type, so that may no be a good idea) or by creating 
overloads for comparing every base class, but it's arguably easier to just 
accept Object and cast - or accept whatever the base type is which first 
introduces opEquals into the hierarchy.

So, there's a good chance that what you'll end up doing is using the base type 
in the hierarchy which introduces opEquals as the parameter for opEquals. This 
is better than using Object in that it'll avoid having completely unrelated 
types even be comparable (as their opEquals wouldn't accept each other), but 
it would still require derived types to use that type as the parameter type 
for opEquals for the reasons mentioned above.

- Jonathan M Davis