Possible way to achieve lazy loading with const objects

Jonathan M Davis jmdavisProg at gmx.com
Thu Sep 29 12:19:48 PDT 2011


On Thursday, September 29, 2011 08:45:18 Andrei Alexandrescu wrote:
> If we make this change we're liable to break all code that defines
> opEquals for classes.
> 
> Two versions should be enough: const/const and mutable/mutable, which by
> default forwards to const/const. Old code will run unchanged at a slight
> efficiency cost due to forwarding. Since it didn't previously work for
> const anyway, no harm done.
> 
> New code gets to only override the const/const version.

So, are we talking about having non-const equals as a temporary thing or as a 
permanent thing? From the discussion on github, I got the impression that we 
were talking about it being permanent. From the discussion here, it sounds 
more like we're talking about having both a const and non-const equals as a 
deprecation path followed by having only a const opEquals. So, which of the 
two are we really proposing here?

- Jonathan M Davis


More information about the Digitalmars-d mailing list