Persistent list

[deadalnix via Digitalmars-d]

On Sunday, 15 November 2015 at 12:56:27 UTC, Andrei Alexandrescu 
wrote:
> On 11/14/2015 05:49 PM, Timon Gehr wrote:
>> List uses RC internally. I don't think the UB casts will stay 
>> for the
>> final version, unless you are willing to completely dilute the 
>> meaning
>> of const in ways that Walter has explicitly expressed will not 
>> be done
>> in the past.
>
> As I mentioned, he's okay with changing the language to make 
> the casts well defined. -- Andrei

Ok Here is what I propose as a spec. This is rough brain dump, 
but that is something I think can be a good start.

There are mutable data that are thread local and immutable data 
that are shared. const is a wildcard type qualifier that can 
refers to mutable or immutable data.

immutable is supposed to be effectively immutable. This means 
that the compiler is allowed to store these data in ro segments 
and optimize redundant loads without having to prove that no 
aliasing write occur in between.

One can cast away const or immutable. It is a @system operation 
and this cast needs to be explicit.

If the underlying data is in ro segment, any write is effectively 
undefined behavior (most likely a fault).
If the underlying data is allocated on the head (using the GC or 
malloc for instance) then writing to it will effectively update 
the underlying memory.

Any read from a const or immutable reference after these write 
can is undefined.
Granted the write was not UB :
1/ Any read from a mutable reference in another thread is 
undefined behavior unless the writing thread release after write 
and the reading one acquire (or any stronger memory barrier).
2/ Any read from a mutable reference in the same thread will see 
the updates in a sequentially consistent manner.

Sounds good ? This definitively allow to do RC for 
const/immutable without throwing away optimization opportunities.