Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

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