Possible way to achieve lazy loading with const objects

[Andrei Alexandrescu]

On 9/29/11 8:38 AM, Steven Schveighoffer wrote:
> On Thu, 29 Sep 2011 11:09:13 -0400, Christophe
> <travert at phare.normalesup.org> wrote:
>
>> "Steven Schveighoffer" , dans le message (digitalmars.D:145738), a
>>>> It is always possible for a non-const version of opEqual to forward to
>>>> the const version, so people willing to use a const version do not have
>>>> to define a non-const version.
>>>
>>> Again, you still need to define both, this is not a good situation.
>>
>> No, I didn't express myself correctly. The non-const version should
>> forward to the const version *by default*.
>
> Fine, but if you want to define a non-const version that *doesn't* call
> the const version, you have to define both. So even if you *don't* want
> to deal with const, you still do. I should have been clearer, sorry.
>
> Note that the compiler currently calls a global method which accepts two
> non-const Objects. In order for it to support both const and mutable
> versions, it would have to have 4 different functions.
>
> I really don't think all this complexity is worth the benefit. Just
> learn to use const properly, or don't use the operator system to do
> comparisons. Object.opEquals should be const.

If we make this change we're liable to break all code that defines 
opEquals for classes.

Two versions should be enough: const/const and mutable/mutable, which by 
default forwards to const/const. Old code will run unchanged at a slight 
efficiency cost due to forwarding. Since it didn't previously work for 
const anyway, no harm done.

New code gets to only override the const/const version.

Where is this wrong?


Andrei