checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/31/2014 10:24 PM, Walter Bright wrote:
>
> Code that relies on assertions being false is semantically broken.
> ...

The code might not rely on it. I.e. the assertion might be the only 
thing that is broken. Turning it into an assumption will additionally 
break the code.

> 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.

EWD liked to say things like:
'The first moral of the story is that program testing can be used very 
effectively to show the presence of bugs but never to show their absence.'.

Which is pedantically speaking obviously wrong without further 
qualification, but he still has a point.

A non-exhaustive sequence of assertion checks will not be sufficient to 
prove that the assertion is true. However, turning the assertions into 
assumptions is valid only if the assertions are true.

Even more importantly, to assume true without proof is very much a 
different operation than to assert true, for proof (or disproof!) to 
come later, and 'assert' awkwardly plays both roles if -release may 
optimize based on it.