How will we fix opEquals?

[Jonathan M Davis]

On Thursday 10 February 2011 00:19:38 Don wrote:
> Andrei once stated a worthy goal: as far as possible, const should be
> opt-in: it should be possible to code without requiring const on
> everything.
> 
> opEquals() is in conflict with this, since it is a member function of
> Object.
> 
> (1) If it is a const member function, then it will have a viral effect
> on all objects -- any function called by opEquals will have to be marked
> const.
> (2) If it is not const, then const objects cannot be compared!
> 
> Currently, it's not const,  but the problem isn't visible because of
> compiler bug 5080. (Same problem applies to opCmp).
> 
> How will we break this dilemma?

Honestly, I think that opEquals should just be const. It doesn't generally make 
any sense for it not to be const anyway. And if Object's opEquals _isn't_ const, 
then const in general is screwed. opEquals, toString, opCmp, and toHash _all_ 
need to be const for const and immutable classes to work in general. I just 
don't think that it's realistic to say that a programmer can totally ignore 
const if they don't want to worry about it.

But for the most part, what does it matter? So, there's a few functions which 
they have to mark as const, because that's the way that they are in Object. That 
doesn't mean that it's viral throughout their program. They can just skip const 
everywhere else.

The _one_ thing that I can think of that's problematic about that approach is 
caching - which would matter for toHash and possibly toString (though changing 
to writeTo would likely make caching on that a non-option anyway). But if they 
_really_ want caching, then can't they just add a second toHash to their class 
and make that one non-const? That one could cache the result, and then the const 
version could use the cached result if it existed.

Realistically, Object _must_ be const-correct for const to work. And if Object 
is const-correct, then anyone overriding those const methods _must_ worry about 
const for those functions. I don't see any way around that. Now, they don't have 
to make any other functions const or declare any variables which are const or do 
anything else with const whatsoever, but toString/writeTo, opEquals, opCmp, and 
toHash _must_ be const or const and immutable objects are screwed, because they 
couldn't call them.

Saying that no one should have to worry about const if they don't want to is a 
noble though, I suppose, but I don't think that it's entirely realistic. const 
is part of the language, and some things just plain have to be const to work. 
And given the prevalence of immutable with regards to threads and the like, 
you're going to be forced to use const in many cases anyway.

I don't think that it's all that big a deal with these 4 functions are const. 
The impact on the programmer is minimal. They can _almost_ ignore const 
completely, since they can still ignore it pretty much everywhere else other 
than with the overriden const Object functions.

- Jonathan M Davis