checkedint call removal

[John Colvin via Digitalmars-d]

On Tuesday, 29 July 2014 at 09:40:27 UTC, Marc Schütz wrote:
> On Monday, 28 July 2014 at 15:52:23 UTC, John Colvin wrote:
>> On Monday, 28 July 2014 at 15:20:44 UTC, Ola Fosheim Grøstad 
>> wrote:
>>> If asserts were used as optimization constraints
>>
>> all available code is fair game as optimisation constraints. 
>> What you are asking for is a special case for `assert` such 
>> that the optimiser is blind to it.
>>
>> bool foo(int a)
>> {
>>    //let's handwrite a simple assert
>>    if(a >= 0)
>>    {
>>        exit(EXIT_FAILURE);
>>    }
>>    //and then do something.
>>    return a < 0;
>> }
>>
>> Of course the compiler is free to rewrite that as
>>
>> bool foo(int a)
>> {
>>    if(a >= 0)
>>    {
>>        exit(EXIT_FAILURE);
>>    }
>>    return true;
>> }
>>
>> Why should the situation be different if I use the builtin 
>> `assert` instead?
>
> The problem is that in release mode, the asserts are removed. 
> It would then be a very big mistake to still take them into 
> account for optimizations, as if they were actually there.
>
> To take your code:
>
>     assert(a >= 0);
>     return a < 0;
>
> is equivalent to
>
>     assert(a >= 0);
>     return true;
>
> but only in non-release mode. In release mode, this effectively 
> becomes
>
>     return a < 0;
>
> which is _not_ equivalent to
>
>     return true;
>
> I believe this is was Ola is protesting about, and I agree with 
> him. Such optimizations must only happen if the check stays.

you mean assert(a < 0) or assert(!(a >= 0)) right?

In a correct program (a necessary but not sufficient condition 
for which is to not violate it's asserts) it is the same.

The program is in error if a > 0, whether the assert is compiled 
in or not. Running in debug mode can simply mean "check my 
assumptions".