On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, "Ola Fosheim Grøstad"
<[email protected]>" wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an
optimization hint.
Saying that a predicate is always true means it's available
to the optimizer.
An assert does not say that the predicate is always true.
Yes, it does. From Meyers' comprehensive tome on the topic
"Object-Oriented Software Construction" (1997) where he writes:
"A run-time assertion violation is the manifestation of a bug
in the software."
-- pg. 346
In fact, Meyers calls it "rule (1)" of assertions.
I would rephrase it as: "An assert says that either the predicate
is always true, or else the program is in an invalid state and
will not operate correctly".
But I do think this entire argument seems to me to be rather
misplaced. I think it's really it's about -release, not about
assert().
The arguments presented by Ola et al mostly seem to be arguments
against the use of the -release switch. Because it is a very
dangerous flag.
If you're removing all your asserts I'd say you're playing a
dangerous game already. If an assert would have failed, but
execution continued anyway, you're in undefined behaviour -- at
the very least, you're in a condition that the programmer
believed could never happen.
If you are disabling your asserts, but still believe that they
may fail, that means you're expecting your program to enter
undefined behaviour! That seems to be a rather illogical position.
I think very strongly that we should rename the "-release"
switch, especially if we do start to make use of asserts. It's
going to cause no end of confusion and passionate debate.
---
In one of the 2013 DConf talks a lint tool was discussed that
disallowed you from you writing a condition that was provably
impossible based on 'in' contracts.
eg:
void foo( int x)
in{
assert(x > 6);
}
body {
if (x > 2) // ERROR! This is always true!
...
}
Which is an interesting approach.
By definition, any optimisations that are performed on the basis
of an assert() that could affect control flow, are detectable
with 100% accuracy by a lint tool. And so, if you wanted to
remove all your asserts but were worried about this issue, it's
detectable at compile time.
