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