Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Thu, 29 Sep 2011 07:52:21 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 09/29/2011 01:33 PM, Steven Schveighoffer wrote:
>> On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
>> <peter.alexander.au at gmail.com> wrote:
>>
>>> On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
>>>> On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
>>>> <peter.alexander.au at gmail.com> wrote:
>>>>
>>>>> I'm happy to not have logical const in D provided that the Object
>>>>> interface (and other similar interfaces) don't require that opEquals
>>>>> is const or any nonsense like that. const means physical const, and
>>>>> opEquals should not require physical const.
>>>>>
>>>>> IMO const/immutable should *only* be used when you need to pass  
>>>>> things
>>>>> between threads i.e. when you *really do* need physical const. If
>>>>> people start using const like you would in C++ then every interface
>>>>> just becomes unnecessarily restrictive.
>>>>
>>>> FYI, this is a bug, not a feature.
>>>>
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>>>>
>>>> It *will* be fixed eventually. The fact that opEquals is not const is  
>>>> a
>>>> huge problem.
>>>>
>>>> -Steve
>>>
>>> I was arguing that opEquals (and co.) should *not* be const. IMO it
>>> would be a huge problem if they were.
>>
>> why? For what purpose do you need to change an object during comparison?
>
> caching computations / calling logically const member functions.

caching computations is an optimization, it's not necessary.

And if logical const were supported, those functions would be const, so  
opEquals could be const too.

But I'm still not convinced that equality comparison is so complex that we  
need either of these.  Do you have any real-world examples?

-Steve