Am 01.08.2014 16:58, schrieb Andrei Alexandrescu:
You may dislike what Walter wanted assert to be, but really this has been it from the beginning. Back in the day when I joined him I questioned the validity of making "assert" a keyword. He explained that he wanted it to be magic in the same way he discusses in this thread.
I'm a bit surprised that back then your reaction was not "well, that's a neat idea, but people must know about it, so let's make it explicit in the documentation".
This seems to be the main problem here: people assumed that assert() behaves like in in C, where it's defined to be a noop when they're deactivated, which pretty much forbids using them for optimizations. So they wanted an assume() that gives the compiler hints about what it can assume a variable to be. Of course it would be desirable if in debug builds assume() would imply assert() so one can find out if those assumptions are not met while testing. With that (C style) mindset, one would not be surprised if the program behaves in an undefined way if an assume() condition is not met at runtime - but one is very much surprised about undefined behavior when a (deactivated!) assert() condition is not met.
If assert() would have been documented or even advertised as "can be used for optimizations by compilers in release mode" from day one, this discussion wouldn't have started or at least would have been over very soon.
Cheers, Daniel
