On 07/15/2016 01:27 PM, deadalnix wrote:
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.
Thanks. Reworked:
"During and after mutating a memory location typed as (unqualified) type
T, no thread in the program (including the current thread) is allowed to
(a) effect a read of the same location typed as const(T) or
immutable(T), or (b) effect a read or write of the same location typed
as shared(T)."
Andrei
