DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

On 04.03.2018 22:49, Walter Bright wrote:
> On 3/4/2018 1:16 PM, Timon Gehr wrote:
>> On 04.03.2018 21:40, Walter Bright wrote:
>>> On 3/4/2018 4:05 AM, rjframe wrote:
>>>> Would I be correct to interpret this as "turn them all off with 
>>>> -release"?
>>>
>>> Array bounds checking is left on with -release.
>>
>> 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.

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

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.