Congratulations to the D Team!

deadalnix deadalnix at gmail.com
Wed Jul 11 06:55:29 PDT 2012


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.


More information about the Digitalmars-d mailing list