Vision for the D language - stabilizing complexity?

[deadalnix via Digitalmars-d]

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.