How will we fix opEquals?

Steven Schveighoffer schveiguy at yahoo.com
Thu Feb 10 06:30:31 PST 2011


On Thu, 10 Feb 2011 09:15:36 -0500, Jason House  
<jason.james.house at gmail.com> wrote:

> 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?
>
> class LazyObject{
>   bool OpEquals(LazyObject);
> }
>
> class Object : LazyObject{
>   override bool OpEquals(LazyObject) const;
>   bool opEquals(const Object) const;
> }
>
> By default, all classes derive from Object, but those that want to  
> ignore viral const or implement lazy calculations can derive from  
> LazyObject.

This doesn't work.  What if the user overrides one and not the other?  Or  
the semantics are different?  Then const objects compare differently than  
non-const ones.

-Steve


More information about the Digitalmars-d mailing list