On Friday, 15 July 2016 at 14:45:41 UTC, Andrei Alexandrescu
wrote:
On 07/14/2016 12:17 PM, Jesse Phillips wrote:
On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh
wrote:
C++ fully defines when it is okay to cast away constness,
gives you
aids so that you know that that's what you are doing, and
nothing
else, and gives you a method by which you can do it without a
cast if
the circumstances support it.
D says any such cast is UB.
Shachar
Yeah C++ defines how you can modify const data after saying
you can
never modify data from a const qualified access path.
§7.1.6.1/3[1]
I still haven't found someone who can explain how C++ can
define the
behavior of modifying a variable after casting away const.
Sure it says
that if the original object was mutable (not stored in ROM)
than you can
modify it, but that is true of D as well, but the language
doesn't know
the object is not stored in ROM so it can't tell you what it
will do
when you try to modify it, only you can.
1.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
Getting back to D, a more appropriate definition that gives us
enough flexibility to implement allocators etc. has to take
time into account. Something like the following:
"During and after mutating a memory location typed as
(unqualified) type T, no thread in the program (including the
current thread) is allowed to effect a read of the same
location typed as shared(T) or immutable(T)."
This allows us to implement portably allocators that mutate
formerly immutable data during deallocation.
Andrei
Read or write.
For const(T) , same thing, but limited to write.
Everything else is UB, as it is already UB at the hardware level.
