On Friday, 1 August 2014 at 01:20:04 UTC, Walter Bright wrote:
On 7/31/2014 3:07 PM, David Bregman wrote:
On Thursday, 31 July 2014 at 18:58:11 UTC, Walter Bright wrote:
On 7/31/2014 4:28 AM, David Bregman wrote:
Sigh. Of course you can assume the condition after a runtime
check has been
inserted. You just showed that
assert(x); assume(x);
is semantically equivalent to
assert(x);
as long as the runtime check is not elided. (no -release)
No. I showed that you cannot have an assert without the
assume. That makes
them equivalent that direction.
That is only true if assert always generates a runtime check.
i.e. it is not
true for C/C++ assert (and so far, D assert) in release mode.
For the other direction, adding in a runtime check for an
assume is going to
be expected of an implementation.
No. It is expected that assume does /not/ have a runtime
check. Assume is used
to help the compiler optimize based on trusted facts, doing a
runtime check
could easily defeat the purpose of such micro optimizations.
I'm rather astonished you'd take that position. It opens a huge
door wide for undefined behavior, and no obvious way of
verifying that the assume() is correct.
It's not a "position". I'm just giving you the definition of
assume so you can understand the difference from assert.
I'm confident that if D introduced such behavior, the very
first comment would be "I need it to insert a runtime check on
demand."
And, in fact, since the runtime check won't change the
semantics if the assume
is correct, they are equivalent.
Right, only "if the assume is correct". So they aren't
equivalent if it isn't
correct.
Q.E.D. ?
I'm not buying those uncheckable semantics as being workable
and practical.
I don't know what this means. Are you saying that you refuse to
admit the difference between assert and assume because you
exclude the possibility of the expression being false (buggy)?
But you still want to assert to become assume in release
mode? How
will you handle the safety issue?
I don't know yet.
I would think the easiest way is to just not inject the
assumption when inside
@safe code, but I don't know anything about the compiler
internals.
Even for @system code, I'm on the fence about whether asserts
should affect
codegen in release, it doesn't seem like a clear tradeoff to
make: safety vs
some dubious optimization gains.
So why do you want assume() with no checking whatsoever? Does
anybody want that? Why are we even discussing such a misfeature?
Ever since my first reply, I've only been trying to
a) help you to understand the difference between the two, and
b) to highlight the safety issue with assume (and the proposal
for assert to become assume in release mode).
Whether I want assume or not is beside the point. If you've
interpreted my posts as some kind of lobbying for the addition of
assume() to D, that is not the case. If you want my opinion on
that, I think it would be a good thing to have assume and assert
separate, for safety and clarity reasons. However the importance
I would assign to adding assume() is low because it is only
useful for very specific micro optimizations, and is always a
tradeoff with its unsafety. In C, I typically use it only a
couple times in a large code base, compared to assert which I use
all over the place.
Do we really want to go down the same road as C
with undefined behavior?
So you don't want assume()? Who does?
I do want assume to some extent (see above), but it wasn't my
point.
