Congratulations to the D Team!

[Jakob Ovrum]

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.