checkedint call removal

[Daniel Gibson via Digitalmars-d]

Am 31.07.2014 04:53, schrieb Walter Bright:
> On 7/30/2014 6:38 PM, Daniel Gibson wrote:
>> I'm in favor of a "harmless" assert().
>> In C(++) I sometimes use things like
>>
>> assert(x != NULL);
>>
>> if(x != NULL) {
>>      x->foo = 42;
>>      // ...
>> }
>>
>> I have that assertion to hopefully find bugs during development and
>> fix them.
>> However, no program is bug free and so it's totally possible that x
>> *is* NULL in
>> some circumstance in the wild (in a "release" mode binary), so I want
>> to make
>> sure it doesn't explode if that happens but handle the problem more
>> gracefully.
>>
>> It would be rather unfortunate if the compiler removed that second
>> check in
>> release mode because the assertion made it assume that x can't be NULL.
>
> Your code is doomed to having problems using assert this way.
>
> 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.

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

Cheers,
Daniel