Inherited const when you need to mutate

[Christophe Travert]

"David Piepgrass" , dans le message (digitalmars.D:172009), a écrit :
>> Now, I recognize and respect the benefits of transitive 
>> immutability:
>> 1. safe multithreading
>> 2. allowing compiler optimizations that are not possible in C++
>> 3. ability to store compile-time immutable literals in ROM
>>
>> (3) does indeed require mutable state to be stored separately, 
>> but it doesn't seem like a common use case (and there is a 
>> workaround), and I don't see how (1) and (2) are necessarily 
>> broken.
> 
> I must be tired.
> 
> Regarding (1), right after posting this I remembered the 
> difference between caching to a "global" hashtable and storing 
> the cached value directly within the object: the hashtable is 
> thread-local, but the object itself may be shared between 
> threads. So that's a pretty fundamental difference.
> 
> Even so, if Cached!(...) puts mutable state directly in the 
> object, fast synchronization mechanisms could be used to ensure 
> that two threads don't step on each other, if they both compute 
> the cached value at the same time. If the cached value is 
> something simple like a hashcode, an atomic write should suffice. 
> And both threads should compute the same result so it doesn't 
> matter who wins.

Yes. It is possible to write a library solution to compute a cached 
value by casting away const in a safe manner, even in a multithreaded 
environment. The limitation is that, if I'm not mistaken, this library 
solution cannot ensure it is not immutable (and potentially placed in 
ROM) when it is const, making the cast undefined.