checkedint call removal

[Walter Bright via Digitalmars-d]

On 7/31/2014 4:36 AM, bearophile wrote:
> (The problem is that your have defined your own idea,

"My" idea is the conventional one for assert - see the Wikipedia entry on it.

   -- http://en.wikipedia.org/wiki/Assertion_(software_development)

Yes, that article also says: "Under abnormal conditions, disabling assertion 
checking can mean that a program that would have aborted will continue to run. 
This is sometimes preferable." The last statement is in contradiction with the 
rest of the article, and I don't agree with it.


> so what I can show you
> will look meaningless or not comformant to your own definition. So this
> discussion is going nowhere. And my original topic drowns in this assume/assert
> debate that is off-topic.)
>
>
> In the case of assume:
>
>
> int max(in int x, in int y) {
>      assume(x > y);
>      return (x > y) ? x : y;
> }
>
> The optimizer is free to replace that code with this, even in debug builds:
>
> int max(in int x, in int y) {
>      return x;
> }

That implies that the behavior is undefined if the assumption is false. A 
compiler is free to add checks for undefined behavior (you yourself are a huge 
proponent of this) and people would (very reasonably for a quality 
implementation) expect that the assumption is checked. Hence, it will behave 
like assert.


> In the case of assert:
>
> int max(in int x, in int y) {
>      assert(x > y);
>      return (x > y) ? x : y;
> }
>
>
> In debug builds gets rewritten as:
>
> int max(in int x, in int y) {
>      if (x <= y)
>          throw new AssertError("...");
>      return x;
> }

Note how that behaves like assume.


> And in release builds gets rewritten as:
>
> int max(in int x, in int y) {
>      return (x > y) ? x : y;
> }

To require that the code be valid with x>y is to misunderstand what contract 
programming is all about. An assert is a contract and must be valid, whether it 
is checked or not. -release is not to be used to deliberately change the 
semantics of code.

For example, from the wikipedia article:

"Assertions are distinct from routine error-handling. Assertions document 
logically impossible situations and discover programming errors: if the 
impossible occurs, then something fundamental is clearly wrong. This is distinct 
from error handling: most error conditions are possible, although some may be 
extremely unlikely to occur in practice. Using assertions as a general-purpose 
error handling mechanism is unwise: assertions do not allow for recovery from 
errors; an assertion failure will normally halt the program's execution abruptly."

Note "LOGICALLY IMPOSSIBLE SITUATIONS", uppercased for emphasis. These are not 
my weird unique made-up-on-the-spot out-of-step ideas.

Code that relies on assertions being false is semantically broken.

In closing, Hoare's paper:

    http://sunnyday.mit.edu/16.355/Hoare-CACM-69.pdf

speaks of "assertions" which can be proven to be true. (It doesn't mention 
"assumptions".) The simplest way to prove it is to put in a runtime check. D's 
assert() nicely fits in with that.