Possible way to achieve lazy loading with const objects

Timon Gehr timon.gehr at gmx.ch
Thu Sep 29 04:52:21 PDT 2011


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.




More information about the Digitalmars-d mailing list