UB in D

[Timon Gehr via Digitalmars-d]

On 09.07.2016 02:26, Walter Bright wrote:
> On 7/8/2016 2:33 PM, Timon Gehr wrote:
>> On 08.07.2016 21:26, Andrei Alexandrescu wrote:
>>> Where is the reference to Walter's promotion of UB in @safe code?
>>
>> Only found this, but IIRC, there was another discussion:
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/C_compiler_vs_D_compiler_272670.html#N272689
>>
>
>
> I don't agree with the notion that all UB's can lead to memory
> corruption. deadalix's hypothetical fails because "proving it always
> passes" cannot be done at the same time as "remove this code path
> because it is undefined".
> ...

It's not the same branch. The code path that is removed ensures that the 
other branch always passes. Anyway, deadalnix was just illustrating how 
a compiler might introduce memory corruption in practice. The 
specification should not /allow/ the compiler to do so in the first 
place. @safe is checked in the front end and UB is exploited by the back 
end. The front end needs to be independent of the back end. Using the 
standard definitions of terms, any UB that makes it into the back end is 
allowed to introduce memory corruption -- the front end cannot know, so 
how can it verify it does not happen?

> I don't agree with the interpretation of UB in C++ that some C++
> compiler authors do ...

Undefined behaviour means the language semantics don't define a 
successor state for a computation that has not terminated. Do you agree 
with that definition? If not, what /is/ UB in D, and why is it called UB?