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