John Regehr on "Use of Assertions"

[Guillaume Boucher]

On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright 
wrote:
> 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.

You only read what you want to hear or what?

His essay is built up in a way where he shows two opposing 
interpretations of
asserts.  Assertions as "bug detectors" or as "optimizer hints".  
He then
discusses which one of those is the better one.  The quote you 
gave is the
definition from a proponent of the "optimizer hint" camp and not 
necessarily what
John agrees with.

His conclusion in the essay is that in general it makes sense to 
have assertions
enabled even in release builds because a slightly worse 
performance is worth it
to have more robust programs and he has backed this up by a lot 
of examples.

Furthermore, he wrote a follow-up post about "assume"
(https://blog.regehr.org/archives/1096).  Assume seems to be what 
you think
assert is, but there is actually a *huge* difference.

> We assert a condition when we believe it to be true in every 
> non-buggy
> execution of our program, but we want to be notified if this 
> isn’t the case. In
> contrast, we assume a condition when our belief in its truth is 
> so strong that
> we don’t care what happens if it is ever false. In other words, 
> while
> assertions are fundamentally pessimistic, assumptions are 
> optimistic.

So no, John doesn't agree with you on this *at all*.