On Wednesday, 30 July 2014 at 15:49:33 UTC, Daniel Murphy wrote:
"Tofu Ninja" wrote in message
news:dtjqnyucskwnqjvks...@forum.dlang.org...
Question?
If an if condition throws or returns in its body is it ok for
the optimizer to 'assume' that the condition is false after
and make optimizations for it? If so then every one
complaining that assert gets removed in -release should really
just be using enforce.
Yes. In fact, it's required that an optimizer do this in order
not to be considered garbage.
The possibility for the optimizer to make the same
optimizations for assert can be done for enforce, the only
difference is that it does not get removed in -release....
Not quite. With enforce, it is impossible (ignoring hardware
or optimizer errors) for the condition to be false if the
enforce was not triggered. Because the assert is not checked,
the condition could be false and the code could do something
awful.
Also, the optimizer can only use the enforce's assumption
_after_ it has checked the condition. Since with assert it
doesn't need to check, it can go backwards and assume the
previous code will never produce a value that can violate the
assertion.
if (y > 7) // x can't possibly be >= 5, so this can't be true
x = y + 1;
assert(x < 5);
if (y > 7) // the program will throw if >= 5, but that doesn't
mean it can't be true
x = y + 1;
enforce(x < 5);
Assert is much much more powerful.
So what is the recommended way of inserting a check of the sort
that Ola would like?
debug enforce(expr);
perhaps? Seeing as that statement is completely missing outside
of debug mode, the compiler can't do anything much about it.
P.S. What about version(assert)? Could the optimiser work with
this:
if(x > 7) x++;
version(assert) auto testResult = x;
assert(x <= 7);
