John Regehr on "Use of Assertions"

[Jonathan M Davis]

On Saturday, September 1, 2018 2:15:15 PM MDT Walter Bright via Digitalmars-
d wrote:
> https://blog.regehr.org/archives/1091
>
> As usual, John nails it in a particularly well-written essay.
>
> "ASSERT(expr)
> Asserts that an expression is true. The expression may or may not be
> evaluated. If the expression is true, execution continues normally.
> If the expression is false, what happens is undefined."
>
> Note the "may or may not be evaluated." We've debated this here before.
> I'm rather pleased that John agrees with me on this. I.e. the optimizer
> can assume the expression is true and use that information to generate
> better code, even if the assert code generation is turned off.

Personally, my concern about letting the compiler optimize based on
assertions has to do with whether it violates @safe. IMHO, it defeats the
purpose of @safe if adding an assertion can result in @system code due to
optimizations. I'm fine with it optimizing so long as the optimizations will
not result in @safe code becoming @system in the case where the assertion
would have failed if it were compiled in. If @safe allows @system
optimizations than it isn't actually @safe, because while we don't want
assertions to ever turn out to be false, they sometimes do turn out to be
false, and if they're not compiled in, it's not going to be caught. That
then is obviously a bug, but at least it isn't one that's going to corrupt
memory (at least if it's in @safe code), but if the compiler is allowed to
optimize based on the assertion to the point that the code could corrupt
memory if the assertion would have failed, then that's a serious problem and
a total violation of the promises made by @safe. And actually, it can't add
@system optimizations even in @system code, because that completely defeats
the ability of the programmer to verify the code for @safety in order to use
@trusted.

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.

- Jonathan M Davis