On Thursday, 18 February 2016 at 11:12:40 UTC, Dicebot wrote:
On 02/17/2016 08:48 PM, Marc Schütz wrote:
On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to
keep, for example, is that any immutable allocation can be
completely put into separate read-only memory.
Yes, and it would be rejected statically (rule 2). I therefor
don't
consider this a problem.
You pretty much prohibit any but typed allocators this way. I
do see it as a problem.
Rule 2 only forbids _static immutables_ with @mutable members,
precisely because those could end up in read-only memory. I don't
see how allocators are affected at all. An allocator would be
mutable, or at least manage mutable memory.
A very important property for building optimized allocators
if you keep in mind sharing goals of immutability.
This is considered too (rule 3). An object can only be
immutable if all its embedded @mutable members are marked as
shared.
That sounds rather weird considering immutable data neither
needs nor synchronization nor CPU cache reloading and @mutable
shared one needs both.
It's a necessary consequence of what you just said. Consider
reference counting: normal const RC objects are thread-local, and
you can use simple increments/decrements to manipulate the
refcounts. Because immutable ones are implicitly sharable, you
need to use atomic operations. Again, this is well encapsulated:
the end-user doesn't get access to the @mutable members.
By the way, the AA approach is troublesome with implicit sharing:
if you declare an immutable RC object that uses a thread-local AA
to store its counters, and it gets sent to another thread, that
one would suddenly find the reference count to be 0 (non-existing
in its own thread-local AA). And I don't see how you could
prevent someone from accidentally doing this with the current
language.
