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.
