On Wednesday, 30 July 2014 at 14:46:20 UTC, Daniel Murphy wrote:
"Wyatt" wrote in message
news:wpyvrdoofziktwqkz...@forum.dlang.org...
I think the point here is that usually, when the optimiser
changes the semantics of valid code, it's considered a bug in
the optimiser.
s/usually/always/
The thing is, code containing an assertion that is not always
true is not valid code.
Seeing this response, my Ordinary Programmer Brain says, "Well
yeah, of course it's not valid once you remove the assertion;
you've fundamentally changed the meaning of the whole thing! If
it were fine to remove the assertion, I wouldn't have used it in
the first place."
Something (possibly the thing where "For fastest executables,
compile with the -O -release -inline -boundscheck=off" is
standard advice to anyone asking about performance) tells me this
point needs to be made MUCH more clear wherever possible or the
ghost of Scott Meyers will haunt us all. But that it's even a
problem tells me we're facing a pattern of human error. Is there
no good way to eliminate it?
It seems pretty clear that there's a class of runtime check that
is for debugging only that can be eliminated because you believe
the code will never be used for evil; and there's a class of
check where, no matter what, if some condition isn't met the
application should immediately halt and catch fire lest it do
something horrible. Additionally raised in this thread is a
class of expression that's only evaluated at compile time for the
sake of making optimisations where you're saying "It's all right,
I made sure this is good, go to town".
The distinction between the former two things in D apparently
comes down to whether you put your assert() as its own expression
or as the ThenStatement of an IfStatement, while the latter has
been conflated into the first. That there's prior art regarding
the terminology and semantics only confuses the issue further.
Incidentally, this conversation actually forced me to look into
the semantics of assert() in C and C++, and it turns out it's
moderately muddy, but it seems they're only eliminated if you
#define NDEBUG?
-Wyatt