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*.
