Head Const

[Marc Schütz via Digitalmars-d]

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.

> 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.

>
>> For example, it's always possible to use a global mutable 
>> associative array to store additional data connected with an 
>> immutable or const object (ignoring purity issues for the 
>> moment). That's safe because from the outside, there's no 
>> observable change to the state of the object itself, and the 
>> global AA's type (shared/thread-local) prevents race 
>> conditions.
>
> Yes and this is how I believe it must be done.
>
>> There's no reason why we can't have the same guarantees for 
>> embedded members, without resorting to an external AA. Have a 
>> look at my DIP [1] for lazy initialization of const members, 
>> which I now realize can be adapted to this use case. 
>> Basically, just replace `lazy` by `@mutable`, and most of the 
>> DIP is still valid. I'll try updating it when I find the time.
>> 
>> [1] http://wiki.dlang.org/DIP85
>
> The problem with this DIP is that it speaks about type system 
> semantics and what matters first is memory model (which is 
> currently very under-defined as soon as you step from a "the 
> GC" world).

I'd say most of the memory model issues are the same as those 
with shared, which is just as undefined currently. That leaves 
possible reordering of accesses to immutable data. I don't have a 
complete answer to that at the moment, but most of it is likely 
also covered by the fact that the @mutable members must be shared 
in this case.

>
> Physical immutability is demanding but it also has great value 
> in its simplicity and being hard to fool. Any language change 
> that is going to reject this notion has to be really strongly 
> justified in terms of what is gained and what is lost and not 
> come simply because expressing such semantics is possible.