assume, assert, enforce, @safe

[Artur Skawina via Digitalmars-d]

On 07/31/14 20:14, Daniel Murphy via Digitalmars-d wrote:
> "Tofu Ninja"  wrote in message news:mhhtxjlrvtqhzztxidbe at forum.dlang.org...
> 
>> With that logic(and the proposed optimizations that this whole thing is about), weird stuff like this happens...
>>
>> void foo(int x)
>> {
>>      if(x != 0) throw ...;
>>      assert(x == 0);
>> }
>>
>> The if check could be removed because assert will be assumed to always be true in release... so x could never not equal 0.... the assert just nuked my scrubbing logic...
> 
> The if can't be removed - and it's fairly easy to see why.  In the control flow path that contains the assert, the compiler is _already_ sure that x == 0.  The assert adds no new information.

As long as the assert is 100% correct. If you have a hundred+ asserts
and a 1% error rate...
A wrong assert could (under the proposed model) propagate the wrong
assumptions both ways. Silently disabling other checks that would
have otherwise caught the error.

Imagine creating a hotfix for some newly discovered bug, and forgetting
to update an assert expression somewhere. Unless the problem is
triggered while testing a non-release build, you may end up shipping a
broken product, even one with bugs that were not present in the original.
Now imagine that somebody else will handle the next report. He/she will
look at the code, see absolutely no problems with it, all necessary
checks will be there... Figuring out that a) an assert is the cause, and
b) which one it is, will be a very interesting process... 


> The corner case is "assert(0)".  It means "if the program got to here, the impossible has happened."

It's vaguely defined, overloaded, and not currently treated that way.
Arguably it could mean 'this path won't ever be reached, trust me', but
redefining it now is obviously not possible. (doing this would of course
make assert(0) extremely dangerous)

artur