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