checkedint call removal

David Bregman via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 30 13:56:35 PDT 2014


On Wednesday, 30 July 2014 at 09:11:31 UTC, Walter Bright wrote:
> On 7/30/2014 12:54 AM, David Bregman wrote:
>> On Wednesday, 30 July 2014 at 03:32:50 UTC, Walter Bright 
>> wrote:
>>> I don't either. I still have no idea what the difference 
>>> between assume(i<6)
>>> and assert(i<6) is supposed to be.
>>
>> assert:
>> is a runtime check of the condition.
>> is a debugging/correctness checking feature.
>> is used when the expression is believed true, but is not 
>> proven so.
>> (if it was proven, then there is no purpose in asserting it 
>> with a redundant
>> runtime check that is guaranteed to never activate.)
>>
>> assume:
>> passes a hint to the optimizer to allow better code generation.
>> is used when the expression is proven to be true (by the 
>> programmer, like
>> @trusted).
>
> It still means the same thing as assert.
>
>
>> The only relation between the two is that if a runtime check 
>> for (x) is inserted
>> at some point, it is safe to insert an assume(x) statement 
>> afterwards, because x
>> is known true at that point.
>
> I.e. they're the same thing.
>
>
>> If assert degenerates to assume in release mode, any bugs in 
>> the program could
>> potentially cause a lot more brittleness and 
>> unexpected/undefined behavior than
>> they otherwise would have. In particular, code generation 
>> based on invalid
>> assumptions could be memory unsafe.
>
> Which is why assert can also do a runtime check.

I think you misread, none of that follows from what I wrote. 
Also, "Nuh-uh, they are too the same" is not a valid argument.

Can you please address the fact that assume is not @safe? How do 
you propose to preserve memory safety in release mode if you 
remove runtime checks for asserts but still assume the condition 
for codegen?


More information about the Digitalmars-d mailing list