Possible way to achieve lazy loading with const objects

Steven Schveighoffer schveiguy at yahoo.com
Thu Sep 29 07:19:37 PDT 2011


On Thu, 29 Sep 2011 09:32:06 -0400, Christophe  
<travert at phare.normalesup.org> wrote:

> "Steven Schveighoffer" , dans le message (digitalmars.D:145729), a
>>> 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?
>
> You may not need to change the object, but you may need to call a
> non-const method. It has been argued against the opponent to transitive
> const that they are not obliged to use const. Then opEqual should not
> oblige them to use const. const is so viral in D that people not willing
> to use const will have to change lines and lines of code to get opEqual
> working.

The argument that you are not obliged to use const is very hollow,  
especially when it comes to Object.  The reality is, whatever Object uses,  
so must you use.  There are no choices.  Either Object is const-aware and  
all your derivatives must be, or Object does not use const, and all your  
derivatives must not.  inout should make this much const more palatable,  
when it gets implemented.  But I think the right move is to make Object  
const-aware.

For structs, I think you should be able to use whatever you want, there is  
no base interface to implement.

> It is always possible for a non-const version of opEqual to forward to
> the const version, so people willing to use a const version do not have
> to define a non-const version.

Again, you still need to define both, this is not a good situation.

-Steve


More information about the Digitalmars-d mailing list