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.
