How will we fix opEquals?

[Steven Schveighoffer]

On Thu, 10 Feb 2011 03:37:58 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> 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.

This isn't really true.  If you make opEquals const, then anything  
opEquals calls must be const.  Inevitably, you need to make a lot of your  
object const, which then goes viral to things that object uses, etc.

On the other hand, I don't think opt-in const is that worthy a goal.   
Things that are const, should be const.

-Steve