checkedint call removal

[Don via Digitalmars-d]

On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
> On 7/31/2014 11:24 PM, "Ola Fosheim Grøstad" 
> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>> On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
>>>> That entry makes no mention of assert being used as an 
>>>> optimization hint.
>>>>
>>> Saying that a predicate is always true means it's available 
>>> to the optimizer.
>>
>> An assert does not say that the predicate is always true.
>
> Yes, it does. From Meyers' comprehensive tome on the topic 
> "Object-Oriented Software Construction" (1997) where he writes:
>
> "A run-time assertion violation is the manifestation of a bug 
> in the software."
>
>     -- pg. 346
>
> In fact, Meyers calls it "rule (1)" of assertions.

I would rephrase it as: "An assert says that either the predicate
is always true, or else the program is in an invalid state and 
will not operate correctly".

But I do think this entire argument seems to me to be rather 
misplaced. I think it's really it's about -release, not about 
assert().

The arguments presented by Ola et al mostly seem to be arguments 
against the use of the -release switch. Because it is a very 
dangerous flag.

If you're removing all your asserts I'd say you're playing a 
dangerous game already. If an assert would have failed, but 
execution continued anyway, you're in undefined behaviour -- at 
the very least, you're in a condition that the programmer 
believed could never happen.

If you are disabling your asserts, but still believe that they 
may fail, that means you're expecting your program to enter 
undefined behaviour! That seems to be a rather illogical position.

I think very strongly that we should rename the "-release" 
switch, especially if we do start to make use of asserts. It's 
going to cause no end of confusion and passionate debate.

---

In one of the 2013 DConf talks a lint tool was discussed that 
disallowed you from you writing a condition that was provably 
impossible based on 'in' contracts.
eg:

void foo( int x)
in{
    assert(x > 6);
}
body {
     if (x > 2)   // ERROR! This is always true!
     ...
}

Which is an interesting approach.

By definition, any optimisations that are performed on the basis 
of an assert() that could affect control flow, are detectable 
with 100% accuracy by a lint tool. And so, if you wanted to 
remove all your asserts but were worried about this issue, it's 
detectable at compile time.