Inherited const when you need to mutate

[David Piepgrass]

> Except that I don't see why Cached!(...) needs to physically 
> separate the mutable state from the rest of the object. I mean, 
> I see that Cached!(...) would have to cast away immutable 
> (break the type system) in order to put mutable state in an 
> immutable object, but if we set aside the current type system 
> for a moment, *in principle* what's the big deal if the mutable 
> state is physically located within the object? In many cases 
> you can save significant time and memory by avoiding all that 
> hashtable management, and performance Nazis like me will want 
> that speed (when it comes to standard libraries, I demand 
> satisfaction).
>
> 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.