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