Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 08:18 PM, Chris Cain wrote:
> On Tuesday, 15 May 2012 at 23:36:38 UTC, Chad J wrote:
>> The idea /was/ to store the @instance variable with the object
>> specifically to avoid complex indirections. Still have to trust
>> programmers though :/
>
> But you /can't/ store the @instance variable with the object. As per the
> language reference, immutables may be stored in ROM. If the object is
> immutable (and const objects might be immutable), then the @instance
> variable would be stored in ROM, in which case it physically couldn't
> change no matter how hard you tried (or it would vomit run-time errors
> or some undefined behavior). The only "workable" solution would be an
> immutable pointer to the mutable variable.
>
> Link: http://dlang.org/const3.html
>

I guess this matters for toHash... so now we not only want 
pure/const/nothrow methods, but there is this implication that we are 
desiring to mutate immutable things.  If we really wanted to overcome 
this, we could have things that behave as if immutable, but carry 
mutable state internally.  These would not be eligible for placement in 
ROM.

The other thing that I'm wondering about is if there are use-cases 
/besides/ hashing.  Are there any?  If not, it might be worth 
special-casing somehow.  It's a difficult route to travel though, 
because it's very difficult to know that there won't be any roadblocks 
besides caching in the future.  Still, I suspect this is not well 
researched.