checkedint call removal

[Walter Bright via Digitalmars-d]

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.