checkedint call removal

[Walter Bright via Digitalmars-d]

On 7/31/2014 6:37 AM, Daniel Gibson wrote:
>> The behavior you desire here is easily handled by creating your own
>> template to exhibit it. See the implementation of enforce() for how to
>> do it.
>>
>
> Now that's a bit surprising to me, as you wrote in the other thread:
>  > 7. using enforce() to check for program bugs is utterly wrong.
>  > enforce() is a library creation, the core language does not recognize
>  > it."
>
> Until now (being mostly a C/C++ guy), I saw assertions as a way to find bugs
> during development/testing that is completely eliminated in release mode (so I
> might still want to handle the asserted conditions gracefully there) - and it
> seems like I'm not alone with that view.

The assert will not cause code to be generated to test the assertion at runtime 
with -release. But the assert must still be valid, and since it is valid, the 
optimizer should be able to take advantage of it.

assert is not meant to be used as "I want my program to be valid even if the 
assert is false".

> Because (in C/C++) assertions just vanish when NDEBUG isn't defined, it would
> never occur to me that they have any influence on such (release mode) builds.
> Doing optimizations on this would just lead to frustration, like several kinds
> of optimizations recently have (e.g. this "compiler will remove bzero() on
> memory that isn't used afterwards" bullshit).

That's the way assert in C/C++ conventionally worked. But this is changing. 
Bearophile's reference made it clear that Microsoft C++ 2013 has already 
changed, and I've seen discussions for doing the same with gcc and clang.

In fact, the whole reason assert is a core language feature rather than a 
library notion is I was anticipating making use of assert for optimization hints.