assume, assert, enforce, @safe

[Jonathan M Davis via Digitalmars-d]

On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
> Am 01.08.2014 22:16, schrieb eles:
>> On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
>>> On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
>>
>>> The debug and the release build may be subjected to different 
>>> input
>>> and hence traverse different traces of abstract states. It is 
>>> not
>>> valid to say that an assertion will never fail just because 
>>> it hasn't
>>> failed yet.
>>
>> Yes, but is the same for the C apps. There, you have no 
>> assertion in the
>> release build, the release build is optimized (I imagine very 
>> few would
>> use -O0 on it...), then the sefault happens.
>>
>
> But there checks are not optimized away because of assert.
> assert(x != NULL);
> if(x != NULL) { ... }
> in C the if check won't be optimized away in NDEBUG builds, in 
> equivalent D code it would, because the assert would make the 
> compiler assume that x will never be NULL at that point.

And why is that a problem? By definition, if an assertion fails, 
your code is in an invalid state, and by compiling out 
assertions, you're basically assuming that they all pass, so 
you're code's already screwed if the assertion would have failed 
had it been compiled in. I don't see how having the compiler then 
use that assertion for optimizations really costs you anything. 
Worst case, it just makes already invalid code more invalid. 
You're screwed regardless if the assertion would have failed. And 
if it would have succeeded, then you just got an efficiency boost 
thanks to the assertion.

Thinking about it, I'm actually wondering if I should use 
assertions _more_ so that the compiler might be able to do better 
optimizations in -release. The extra cost in non-release builds 
could be worth that extra boost in -release, and as far as 
correctness goes, it never hurts to have more assertions.

- Jonathan M Davis