Possible way to achieve lazy loading with const objects

[Peter Alexander]

On 29/09/11 6:50 PM, Steven Schveighoffer wrote:
> On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
> <peter.alexander.au at gmail.com> wrote:
>
>> On 29/09/11 12: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?
>>
>> The comparison may involve comparing a sub-object that is lazily
>> created. It could also involve computing a cached perfect hash for
>> faster comparison, requiring memoization.
>
> Neither of these are required for opEquals to work. They are optimizations.

So what you're saying is that, in D, I'm not allowed to optimize my 
opEquals and that I should be fine with that?