DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

On 05.03.2018 11:30, Walter Bright wrote:
> The idea behind removal of the runtime checks is as a performance 
> optimization done on a debugged program.

Optimizing performance is fine, but why pessimize safety? The hints will 
usually not make a significant difference in performance anyway. I guess 
it is fine to have a compiler option that is all speed no safety, but it 
should not be the only option.

> It's like turning on or off array bounds checking.

It is not.

void main()@safe{
      int[] x=[];
      writeln(x[0]); // range violation even with -release
                     // defined behavior even with -boundscheck=off (!)
}

If I now add an assertion, I suddenly get UB:

void main()@safe{
     int[] x=[];
     assert(0<x.length); // obviously this should hold, or next line is 
invalid
     writeln(x[0]); // UB with -release
}

I did not make the code any more wrong by adding the assertion.
Why should I get more UB?


> Many leave asserts and array bounds checking on 
> even in released code to ensure memory safety.
> ...

Maybe the requirements change and it is now too costly to leave 
contracts on in release mode, or the number of contracts in the code 
base slowly accumulates until we reach a point where the total cost is 
too large, or we replace a library, and the new version has costly 
contracts, etc. Now we have the following options:

- Leave contracts in -- fail performance requirements.

- Remove contracts -- fail safety requirements.

- Track down all 'assert's, even those in external libraries, and 
replace them by a custom home-cooked solution that is incompatible with 
everyone else's -- fail maintainability requirements.

To me this situation is ridiculous.

> At a minimum, turning it off and on will illuminate just what the checks 
> are costing you.
> ...

Well, no. If the bug is elusive enough to not have shown up in debug 
mode, it probably won't be seen early during -release testing, and even 
if it does, the UB may mask it. (Note that when the program becomes 
faster, the likelihood of timing-dependent bugs showing up may change.)

I.e., if something goes wrong, it is likely that you won't see the 
safety costs until it is too late.

> It's at the option of the programmer.

It is not, but I want it to be. That's all I want. [1]

I'm just saying there should be the following option:

- Remove contracts -- sufficient performance and retain memory safety.

FWIW, this is what all contract systems that I'm aware of do, except D, 
and maybe C asserts in certain implementations (if you want to call that 
contracts).


[1] Well, maybe add a @system "__assume" intrinsic.