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