Persistent list

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Tue Nov 17 12:21:55 PST 2015


On Tuesday, 17 November 2015 at 01:58:54 UTC, deadalnix wrote:
> 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.

Just quoting myself. In case someone is interested...



More information about the Digitalmars-d mailing list