checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/31/2014 09:19 PM, Walter Bright wrote:
> 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".
> ...

An assert does not have any bearing on program validity if assertions 
are disabled.

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

Right. Note 'conventionally' as in 'convention'. Why break the convention?

> But this is
> changing. Bearophile's reference made it clear that Microsoft C++ 2013
> has already changed,

No way, their assert macro conforms to the standard. 
http://msdn.microsoft.com/en-us/library/9sb57dw4.aspx

> and I've seen discussions for doing the same with gcc and clang.
> ...

And I've seen discussions for introducing silent breaking changes into 
D. It usually didn't happen. Why are those discussions deemed to be 
_more relevant than the standard_ in the first place?

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

I was under the impression it was because of assert(0).