DIP 1006 - Preliminary Review Round 1

[Walter Bright]

On 3/5/2018 11:34 AM, Timon Gehr wrote:
> On 05.03.2018 11:30, Walter Bright wrote:
>>The hints will usually not make a significant difference in performance anyway.

Reasonable people will disagree on what is significant or not.


>> 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 (!)

It is not defined behavior 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?

Because you put in an assert that did not hold, and disabled the check.


> 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.

It's completely under the control of the programmer. I know you disagree with 
that notion. You can even create your own `myassert` to produced your desired 
semantics.


> 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).

D is better (!).

(C's asserts are not part of the language, so impart no semantics to the compiler.)