Le 04/10/2011 20:30, Walter Bright a écrit :
On 10/4/2011 2:32 AM, deadalnix wrote:
With casts to immutable, it is perfectly correct if you, the user,
ensure that there are no other mutable references to the same data. It's
just that the compiler itself cannot make this guarantee, hence it's
"unsafe".
Casting from immutable to mutable, on the other hand, is "undefined
behavior" because neither the compiler nor you, the user, can guarantee
it will work.
This looks like more a flaw in the type system or lack of tools to deal
with the type system than a real allocation issue.
I see two solutions to deal with this :
Something allocated on a Thread local heap can be seen from other
threads, and this is safe as long as a reference is kept in the
allocating thread.
So, if you cast something TL and mutable as immutable, you have to
ensure yourself that you will not modify it. Plus, you need to ensure
that you keep a reference on that object in the allocating thread,
otherwise, you'll see it collected.
A shared casted as immutable should exprience any issue.
The other apporach is to give a way to explicitely say to the compiler
that this will be casted as shared/immutable at some point and should be
allocated on the corresponding heap.
Thoses two solutions are not exclusives and can be both implemented.
Maybe I'm wrong, but it doesn't seems that the issue is that big.
Anyway, thoses thing have a big impact, so they should be considered
several times.