On Wednesday, 11 July 2012 at 01:19:16 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate
the logical
const stuff, and then cast the reference to const to use
inside the
opEquals.
s/straightforward/awful/
Andrei
Honestly, I think the ideal would be to give people the
alternative of having a mutable opEquals etc. These methods only
need to be logically constant (of course, they don't *need* to be
even that, to the joy of operator overloading abusers worldwide),
which means no help from the compiler, as it should be - just
plain mutable, with the programmer providing the guarantee.
There was work in this direction but I understand it was ripe
with issues of its own, however I don't understand how any other
path could even be considered when it's just moving from one end
of the scale to the other.
Yes, Object *needs* to work with const, this is imperative. But
does it need to compromise on implementations relying on
mutability? I was hoping the answer was "no". Obviously such an
override would not work with const references, but some classes
really don't lean themselves to immutability at all, alleviating
the need for const. I can also imagine that if both were allowed,
someone would leverage the ability to use caching in the mutable
overload, then falling back to eager computation in the const
overload.
