Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Thu, 29 Sep 2011 14:59:25 -0400, Peter Alexander  
<peter.alexander.au at gmail.com> wrote:

> 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?

Or use a method other than opEquals.  Or overload opEquals (this really  
should be possible) for your specific needs.

Again, I ask, what is a real-world example of something that needs lazy  
caching (or where lazy caching significantly helps performance) for  
comparison.  You have already stated that you appreciate it's not const,  
so you must have *something* that needs it.

So far, I don't think it's a very common requirement.  It certainly  
doesn't seem like it's so important that the entire body of D code in  
existence should have to deal with mutable opEquals.  The fact that it's  
mutable now is really a legacy D1 issue.

-Steve