On Sunday, September 2, 2018 1:52:34 PM MDT John Colvin via Digitalmars-d
wrote:
> > If the compiler can add @safe optimizations based on
> > assertions, then that's fine with me (though I know that some
> > others don't agree), but they have to be @safe even when the
> > assertion would have failed if it were compiled in. If they're
> > ever @system, then @safe isn't actually @safe.
>
> I believe asserts are the general case of which bounds checking
> is a specific instance. @safe code is only @safe if
> bounds-checking is enabled for @safe.
>
> void foo(int[] a) @safe
> {
> a[0] = 1;
> }
>
> is only really guaranteed safe if a bounds check is done, because
> [] is a valid array for a caller to pass.
Well, if that were the intention, then -release could not remove assertions
from @safe code. -release does not remove bounds checking from @safe code.
You have to use -boundscheck=off to disable assertions in @safe code (which
is of course discouraged, since it makes the code not @safe). So, if we were
to decide that assertions had to be left in for code to stay @safe, then we
would have to start leaving them in in @safe code when -release is used and
only compile them out with a new flag specifically for compiling out
assertions in @safe code. And that would have pretty far-reaching effects
given that it's very much understood right now that -release removes
assertions. And personally, I'd probably use assertions a lot less if they
were going to be left in with -release. So, while I think that that's a
better approach that allowing @system optimizations in @safe code when
assertions are removed, I can't say that I think that it's a great idea -
though the folks who pretty much always want assertions enabled would
probably like it (though they can already just skip -release).
- Jonathan M Davis
