Assert and undefined behavior

[John Burton]

On Thursday, 12 October 2017 at 14:22:43 UTC, Timon Gehr wrote:
> On 11.10.2017 11:27, John Burton wrote:

> Yes, that's what it is saying. (The other answers, that say or 
> try to imply that this is not true or true but not a bad thing, 
> are wrong.)
>
> ...
> 
>
> However, in practice, I think none of the current compiler 
> implementations actually uses assert expressions for 
> optimizations.

This is an example of what I mean :-

import std.stdio;

extern void control_nuclear_reactor(int[] data);

void test(int[] data)
{
     if (data.length == 0) {
         writeln("Not enough data!");
     } else {
         control_nuclear_reactor(data);
     }

     assert(data.length > 0);
}

So according to the spec, if data is size zero then the assert 
fails and therefore the code has **undefined behavour**. What 
this means in practice is that the compiler decides that it 
doesn't matter what code is generated for that case as it 
undefined what it is meant to do anyway, so the compiler can 
"optimize" out the if condition as it only affects the case where 
the language doesn't define what it's supposed to do anyway, and 
compiles the code as if it was :-

void test(int[] data)
{
     control_nuclear_reactor();
}

Which obviously could have very bad results if the test mattered.

Yes my program is invalid because I violated it's assumptions but 
I find it very hard to argue that including the assert should 
"break" the code before it.

C++ compilers can and do perform such optimizations so I was 
wondering if assert in D could cause such behavior according to 
the spec.