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.
