Possible way to achieve lazy loading with const objects

Steven Schveighoffer schveiguy at yahoo.com
Wed Sep 28 06:45:28 PDT 2011


On Wed, 28 Sep 2011 06:22:14 -0400, Christophe  
<travert at phare.normalesup.org> wrote:

> "Steven Schveighoffer" , dans le message (digitalmars.D:145415), a
>  écrit :
>> 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
>
> Why would it be such a huge problem, as long as there is both non-const
> and const overload ?

Having multiple overloads is not good either.  Then you have to overload  
both to have pretty much the same code.

Also note that the way the compiler compares objects is not conducive to  
multiple overloads.

const covers all three constancies (mutable, const, immutable), why is  
that one overload not enough?

One aspect which will be interesting to tackle (if desired at all) is  
comparing shared objects.  We *would* need another overload for that.

-Steve


More information about the Digitalmars-d mailing list