How will we fix opEquals?

[Steven Schveighoffer]

On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 2/10/11 2:58 AM, Peter Alexander wrote:
>> On 10/02/11 8:19 AM, 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?
>>
>> It's not possible.
>
> It is, in fact, possible. We can define two opEquals overloads, for  
> const and non-const. By default, the non-const version forwards to the  
> const one.

This doesn't work.  If you only define one, then you will have problems  
with hidden function errors, and/or inconsistencies.  For example, how  
does .opEquals(Object obj1, Object obj2) know which version to call?

I think the only true solution is to make it const and call it a day.

-Steve