Possible way to achieve lazy loading with const objects

Steven Schveighoffer schveiguy at yahoo.com
Thu Sep 29 04:33:32 PDT 2011


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?

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

I haven't seen that statement.

-Steve


More information about the Digitalmars-d mailing list