Am 31.07.2014 22:57, schrieb Andrei Alexandrescu:
On 7/31/14, 12:37 PM, Daniel Gibson wrote:
This thread however shows that many D users (who probably have more D
experience than myself) are not aware that assert() may influence
optimization and would prefer to have separate syntax to tell the
optimizer what values he can expect.
Yah, I think that's a good outcome. We must document assert better. --
Andrei
You should have done so 10 years ago.. experienced D coders (that don't
follow this discussion) probably won't look up what exactly assert()
does again and and code will silently break in subtle ways once the
optimizer uses assert()
But if you (as in "the D language implementors") *really* decide to
stick to this unexpected meaning of assert(), you should indeed document
this as soon as a proper definition of what assert() does and might do
in the future, when enforce() vs assert() should be used.
Maybe, besides enforce() and assert() there could be a check() that:
* returns true if the condition is true
* throws an exception in debug mode if the condition is false
* returns false in release mode if the condition is false
could be introduced.
It could be used like
if(check(x !is null, "x must not be null")) {
// .. do something with x ..
}
to cater the usecase of "in debugmode I want to know about this
problem/behavior immediately to debug it, but in releasemode I want to
handle it gracefully".
Cheers,
Daniel
