assert semantic change proposal

[Daniel Gibson via Digitalmars-d]

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