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

[Jonathan M Davis]

On Monday, March 18, 2013 00:53:52 Stewart Gordon wrote:
> Why would some class want to implement these methods in a way that alters
> the object?

Because const in D is physical const, not logical const. So, for instance, 
const prevents caching. And it's quite possible that a type which really cared 
about efficiency would cache the calculated value for toHash. Make toHash const 
would make that impossible. Another possible problem would be lazy 
initialization. If opEquals is const, then lazy initialization becomes 
impossible.

We've discussed this on a number of occasions, and it's clear that forcing 
these functions to be const is a major problem, and yet they do need to be 
const for them to work with const objects. What was finally decided during the 
last big discussion on this a few months back was that we would remove 
opEqulas, opCmp, toHash, and toString from Object. They don't need to be 
there. As long as everything in the runtime which deals with them is 
templated, then there's no technical reason why Object would need them. D 
isn't Java where we have containers of Object or anything like that. Putting 
them on Object just restricts us.

So, once all of those functions are removed from Object, derived types can 
then define them with whatever attributes they want. The only thing you lose is 
the ability to compare Objects directly, which is not necessary in D and is 
arguably a bad idea anyway.

The work on this conversion hasn't been done yet, and a transition plan will 
have to be put in place to minimize code breakage, but that's what was decided 
on as the solution to the issues with const and Object's functions.

- Jonathan M Davis