checkedint call removal

[Walter Bright via Digitalmars-d]

On 7/31/2014 12:37 PM, Daniel Gibson wrote:
> Am 31.07.2014 21:19, schrieb Walter Bright:
>> 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.
>
> This will break so much code :-/

Maybe you're right. I've always thought that assert() was a simple and obvious 
concept, and am genuinely surprised at all the varied (and even weird) 
interpretations of it expressed here. I've never heard such things in my 30+ 
years of using assert().

I have seen some misuse of assert() before, but the author of them knew he was 
misusing it and didn't have an issue with that.

I can't even get across the notion of what a program's inputs are. Sheesh.

Or perhaps some people are just being argumentative. I can't really tell. I can 
tell, however, than many of these sub-threads have ceased to contain any useful 
discussion.



>> 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.
>
> So why is this not documented?

Frankly, it never occurred to me that it wasn't obvious. When something is 
ASSERTED to be true, then it is available to the optimizer. After all, that is 
what optimizers do - rewrite code into a mathematically equivalent form that is 
provably the same (but cheaper to compute). Its inputs are things that are known 
to be true.

For example, if a piece of code ASSERTS that x is 3, thereafter the optimizer 
knows that x must be 3. After all, if the optimizer encounters:

    x = 3;

do I need to then add a note saying the optimizer can now make use of that fact 
afterwards? The use of "assert" is a very strong word, it is not "maybe" or 
"possibly" or "sometimes" or "sort of".

When you write:

    assert(x == 3);

then at that point, if x is not 3, then the program is irretrievably, 
irredeemably, undeniably broken, and the default action is that the program is 
terminated.

The idea expressed here by more than one that this is not the case in their code 
is astonishing to me.


> The assert documentation isn't even clear on when an AssertError is thrown and
> when execution is halted (http://dlang.org/contracts.html doesn't mention halt
> at all).
> And it says "When compiling for release, the assert code is not generated." - if
> you implemented assert like this so the optimizer can assume the assertion to be
> true even when "assert code is not generated" this is certainly something
> developers should be very aware of - and not once you actually implement that
> optimization, but from day one, so they can use assert accordingly!

I agree it is now clear that the documentation needs to be clarified on that 
point. What I considered as obvious apparently is not.


> This thread however shows that many D users (who probably have more D experience
> than myself) are not aware that assert() may influence optimization and would
> prefer to have separate syntax to tell the optimizer what values he can expect.

It's also true that many D users are unclear what data flow analysis is, how it 
is used in compilers, and the state of the art of such optimizations. And they 
shouldn't need to. D would be a terrible language indeed if only compiler guys 
could write successful programs with it.

What users do need to understand, is if they write:

     assert(x < 10);

that at that point in the code, they are GUARANTEEING that x is less than 10, 
regardless of compiler switches, checked or not, and that the program is 
absolutely broken if it is not.

And let the compiler take it from there.