assume, assert, enforce, @safe

[Daniel Gibson via Digitalmars-d]

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