DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

On Tuesday, March 06, 2018 17:01:04 Paolo Invernizzi via Digitalmars-d 
wrote:
> On Tuesday, 6 March 2018 at 16:30:09 UTC, John Colvin wrote:
> > On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote:
> >> On 3/5/2018 2:30 PM, John Colvin wrote:
> >>> This just feels bad. Adding extra failsafes for my debug
> >>> program shouldn't make my release program less safe.
> >>
> >> Then use `enforce()`.
> >
> > So, to clarify, adding asserts to my code makes my release
> > builds violate @safe?
>
> Only if the assert does not hold, you have _not_ tested it, and a
> future optimiser will use the assert expression for some hints
> that generated broken code.
>
> At the end, I'm with Walter: you should have tested the code with
> the assert enabled, and you should have noticed that the assert
> it's not holding _before_ running the code in release without
> them.

The problem with this approach is that even if you have tested your code
well, sometimes you miss things, and then you have bugs. And that's life,
but with @safe, you're not supposed to then up with memory safety problems.
That's why array bounds checking is not removed in @safe code even with
-release. Yes, well-tested code would hopefully not need the checks anymore,
but bugs still creep in, and if the array bounds checking is removed, then
you can end up with memory corruption.

This issue is really no different from array bounds checking, and I don't
see any reason to treat it any differently. @safe could should be guaranteed
to be @safe so long as @trusted is used correctly. The compiler should not
be assuming that the programmer has done a perfect job of testing and caught
every possible bug and that there's no way that an assertion would have
failed if it were still compiled in and that it is thus safe to introduce
optimizations which would not be memory safe if the assertion would have
failed. If the compiler does that, then @safe is being violated, which the
compiler should never be doing.

- Jonathan M Davis