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