On Wed, Jul 30, 2014 at 06:18:22PM +0000, Wyatt via Digitalmars-d wrote:
[...]
> It seems pretty clear that there's a class of runtime check that is
> for debugging only that can be eliminated because you believe the code
> will never be used for evil;
assert(...)
> and there's a class of check where, no matter what, if some condition
> isn't met the application should immediately halt and catch fire lest
> it do something horrible.
enforce(...)
> Additionally raised in this thread is a class of expression that's
> only evaluated at compile time for the sake of making optimisations
> where you're saying "It's all right, I made sure this is good, go to
> town".
[...]
The proposal is to fold this meaning into assert() as well. I see no
harm in doing this, because:
1) When compiling in non-release mode:
assert(...) means "I believe condition X holds, if it doesn't I
screwed up big time, my program should abort"
assume(...) means as "I believe condition X holds, if it doesn't
I screwed up big time, my program should abort"
2) When compiling in release/optimized mode:
assert(...) means "Trust me, I've made sure condition X holds,
please optimize my code by not bothering to check
condition X again"
assume(...) means "Trust me, I've made sure condition X holds,
please optimize my code by making use of condition X"
Certainly, making assert==assume extends the current meaning of assert
in (2), but I don't see the incompatibility. In both cases under (2) we
are *assuming*, without proof or check, that X holds, and based on that
we are making some optimizations of the generated code.
I can't think of a real-life scenario where you'd want to distinguish
between the two kinds of optimizations in (2). Sure, in theory there's
a conceptual distinction between the two cases, but I don't see what
difference this makes in practice. It's splitting hairs over
philosophical issues that ultimately don't matter in practice.
T
--
Век живи - век учись. А дураком помрёшь.
