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.
