DIP 1006 - Preliminary Review Round 1

[Walter Bright]

On 3/4/2018 3:06 PM, Timon Gehr wrote:
> On 04.03.2018 22:49, Walter Bright wrote:
>>> Not necessarily. If the code contains an explicit assertion that the index is 
>>> in bounds, then, according to the language specification, the bounds check 
>>> may be removed with -release.
>>
>> D, as all languages that I know of do implicitly or explicitly, generates code 
>> based on the "as if" rule.
>> ...
> 
> Impossible. You wrote a Java compiler.

Even in Java, the compiler generates code that, from the user's point of view, 
behaves "as if" the code was actually what was specified. For a trivial example, 
replacing x*2 with x<<1. Not having this means no optimizations can be done.


> All languages that use your "as if" rule are memory unsafe.
> Zero languages that use the "as if" rule have any memory safe subset that 
> includes assertions.
> In D, assert is @safe, and it should remain @safe.

>>> I find the reasoning in terms of "on"/"off" confusing anyway.
>>> Does "off" mean "contract/assertion removed", or does it mean "failure is UB"?
>>
>> "Off" means the check is removed. If the check does not hold, the program 
>> enters an invalid state, whether or not the check was actually done. An 
>> invalid state means subsequent execution is UB.
> 
> Why is potential memory corruption to be expected when using @safe language 
> features with a flag to disable contract checks?

Because the checks provide extra information to the compiler that it can use to 
generate better code. If that extra information is not true, then the better 
code will be invalid.

Memory safety is only one class of errors in a program. If the program has 
entered a state that is not accounted for by the programmer, the rest of the 
program's execution will be not predictable.


> This makes no sense. This is 
> not useful behavior. There are convenient ways to support potentially unsound 
> compilation hints that do not do this. Contracts and compilation hints should be 
> orthogonal. Contracts should be potentially @safe, compilation hints should be 
> @system always.
> 
> Note that _actual removal_ is the only use case of 'disabling contracts' that I 
> care about, and I think many D programmers who use "off" will also have this 
> behavior in mind. Yet this is not even an option.

I don't see much use for this behavior, unless you want to continue running the 
program after an assert failure, which I cannot recommend and the language is 
not designed to support. But you can always do something like:

    version (ignore_asserts) { } else { assert(...); }

which would optionally remove both the runtime check and any compiler use of the 
assert. Or you could use https://dlang.org/library/std/exception/enforce.html 
which has no influence on compiler semantics.


> At the very least, the DIP should be up-front about this.
> I'm still not even sure that Mathias Lang intended the UB semantics.

It being UB was my doing, not Mathias'. DIP1006 is not redefining the semantics 
of what assert does.