Head Const

[Marc Schütz via Digitalmars-d]

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.