Possible way to achieve lazy loading with const objects

[Peter Alexander]

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.


>> Andrei says that it will (in a way) be both, so I'm happy with that.
>
> I haven't seen that statement.

I can't find it, but he said that there will be two versions: a const 
version and a non-const version. By default, the non-const version will 
forward to the const version, so you only have to implement one.