Am 03.08.2014 22:05, schrieb bachmeier:
Thanks for the summary. I apologize for the uninformed question, but is
it possible to explain how the change wrt assert will break existing
code? Those details are probably buried in the extensive threads you've
referenced. I ask because my understanding of assert has always been
that you should use it to test your programs but not rely on it at runtime.
Example:
assert(x !is null);
if(x !is null) { x.foo = 42; }
in release mode, the assert() will (as to Walters plans) tell the
compiler, that x cannot be null, so it will optimize the "if(x !is
null)" away.
Currently this would not happen and this code won't segfault, with that
optimization it would, in case in release mode x is null after all in
some circumstance that hasn't occured during testing.
Walters stance on this is, that if x is null under some circumstance,
the program is buggy anyway and in an undefined state.
Furthermore he interprets "assert()" as "the programmer asserts (as in
promises) that the given condition is true".
Other people say that assert(), as it's implemented in many programming
languages (including D up to now), just is a runtime check with a funny
name that can be deactivated (e.g. for/in release builds).
Some have proposed to have an assume() that does what Walter wants
assert() to do.
Cheers,
Daniel
