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.
