On 8/1/2014 4:53 AM, Don wrote:
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.
Yes. (At the very least, the switch will tell you how much runtime speed the
asserts cost you.) Asserts not only can detect programming bugs, they can
provide optimizer hints that significantly improve code generation. It's going
to be necessary to keep D competitive in high performance computing.
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.
Of course. Don't ask the Godfather to do favors for you if you are unwilling to
return the favor :-)
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.
The name came about as a result of my experience with newbies benchmarking my
compilers and publishing the results. They'd spend 2 or 3 seconds scanning the
documentation to figure out how to set up the compiler to generate the fastest
code. -disableasserts is meaningless to them, and they won't use it, and the
compiler would fare poorly. -release speaks to them "faster code", so they use
that one.
It's worked out well for that purpose.
I would expect someone who spends more time developing code with the compiler to
spend at least a little effort reading the two lines of documentation for
-release and understanding that it disables the runtime assert checks.
I agree that the documentation can be improved.
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.
When writing generic code, or any generative code, these situations can come up
a lot and be legitimate.
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.
You're right, but that means the lint tool would have to replicate the data flow
analysis in the optimizer, and would have to account for different DFA as
implemented in each D compiler.
