assume, assert, enforce, @safe

David Bregman via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 31 04:28:40 PDT 2014


On Thursday, 31 July 2014 at 08:08:43 UTC, Walter Bright wrote:
> On 7/31/2014 12:40 AM, David Bregman wrote:
>> On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright 
>> wrote:
>>> I'd like to sum up my position and intent on all this.
>>>
>>> 1. I can discern no useful, practical difference between the 
>>> notions of assume
>>> and assert.
>>
>> People have explained the difference repeatedly, a ridiculous 
>> number of times
>> now. Could you please take a minute to understand it this time 
>> instead of
>> flippantly dismissing it again?
>>
>> assert does a runtime check, assume does not
>> assume affects code generation/optimization, assert does not
>> assert is for debugging, assume is not
>> assume is for optimization, assert is not
>>
>> In terms of what they practically do, they have *nothing* in 
>> common, their
>> functions are entirely orthogonal.
>
> They are inextricably entangled. Consider:
>
>    if (x == 0) abort();   // essentially what assert(x) does
>    ... at this point, the optimizer knows, beyond doubt, that 
> x!=0 ...
>    if (x)  // optimizer can remove this check
>       ...
>
> which has the behavior of assume as you listed above, yet it is 
> assert. We can pretend assert doesn't affect code, like we can 
> pretend to have massless points in physics class, but in 
> reality points have a mass and assert most definitely affects 
> code generation, and does in every compiler I've checked, and 
> it affects it in just the way the assume does.
>
>
>> Still think there is no practical difference?
>
> Yes.

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)

You didn't show that assert and assume are the same, they are not.

The code generated by one will be different than the code 
generated by the other, that is because they are functionally 
different. This is really indisputable..

>
>
>>> 2. The compiler can make use of assert expressions to improve 
>>> optimization,
>>> even in -release mode.
>>
>> This will introduce a lot of undefined behavior, including 
>> making @safe code
>> with asserts unsafe. I really think this needs to be 
>> acknowledged. As far as I
>> can tell from the other thread, it still hasn't been.
>
> I did acknowledge it for the array bounds case.

Ok, thanks! But you still want to assert to become assume in 
release mode? How will you handle the safety issue?

>
> Note that your assume() will have the same effect, and worse, 
> there will be no option to have the compiler insert a check, 
> because then it would be an assert() and you might as well just 
> use assert().

So what? I did not suggest to use assume() instead of assert() to 
avoid the problem. In fact, that _is_ the problem, _you_ are 
suggesting that assert becomes assume in release mode. assume() 
is not @safe, that is the whole point.



More information about the Digitalmars-d mailing list