assume, assert, enforce, @safe

[David Bregman via Digitalmars-d]

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.