On 11/07/2012 03:30, Jakob Ovrum wrote:
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.
The cached value can in fact rely outside the object.
private string[const MyObject] cache;
class MyObject {
override string toString() {
return cache.get(this, complexCalculationOfToStringWeNeedToCache);
}
~this() {
cache.remove(this);
}
}
This really isn't a problem. This is even thread safe. cache can be made
static into MyObject too. Actually, plenty of solutions exists.
