How will we fix opEquals?

[Andrei Alexandrescu]

On 2/10/11 9:33 AM, Steven Schveighoffer wrote:
> 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?

You define two: const taking a const, and nonconst taking a nonconst.

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

In fact I agree. Doubling the number of basic Object members has other 
nefarious circumstances.


Andrei