checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/30/2014 02:48 AM, Walter Bright wrote:
> On 7/29/2014 3:02 PM, Timon Gehr wrote:
>> They are dual concepts. Assert demands a property to hold, assume
>> provides a
>> property that holds.
>
> A distinction without a difference.

Wtf.

(Imagine you are arguing with someone who keeps claiming that the 
distinction between @trusted and @safe is meaningless and you are 
roughly in my position.)

> potayto, potahto
> ...

potato.

>
>> 1. This particular behaviour is characteristic for an assumption, not an
>> assertion, according to the above characterisation, which is standard
>> in certain
>> communities, like people who are into verification of procedural
>> programs.
>>
>> 2. Code containing such a construct must in general be monitored to
>> ensure
>> memory safety, hence can at most be @trusted.
>
> ??
> ...

Undefined behaviour does not preserve memory safety.

>
>> I was just pointing out how to properly prevent optimization based on
>> disabled
>> assertions.
>
> ??
> ...

Maybe you weren't following the discussion. What do you think this 
discussion is about?

On 07/28/2014 03:31 PM, Daniel Murphy wrote:
> "Ola Fosheim Grøstad" " wrote in message
> news:vqlvigvgcplkuohudsju at forum.dlang.org...
>
>> Please guys, you should not change code-gen based on asserts. They are
>> not proofs, they are candidates for formal verification of
>> correctness. They are in essence embedded break-point checks. If you
>> allow asserts to affect codegen then it becomes a very unsafe feature.
>> It's like having a undetected bug in a unit-test introduce bugs in the
>> released program. 8-I
>
> The compiler is allowed to not check assertions in release mode.  This
> is because a program that would fail an assertion is a broken program,
> and by specifying -release you are telling the compiler to assume all
> assertions pass.  I don't see any reason the compiler shouldn't be
> allowed to change code-gen based on asserts.
> ...

This is what spawned this subthread. Does this clear up your question marks?

>
>> (Unless, of course, you want to tell me a compiler may assume that
>> anything in a
>> version(assert) block can be assumed to actually be part of the
>> program by the
>> optimizer, which is very hard to implement, and may not even make
>> sense in all
>> circumstances.
>
> I don't know what you're assuming (!) the version(assert) even does, as
> it is not a language feature.
> ...

Of course version(assert) is a language feature. Always double-check 
your claims.

It's even documented: http://dlang.org/version.html

>...
>
>> I hope this post cleared it up a little.
>
> Not a bit. The distinction utterly escapes me.

This is unfortunate, but I don't know what else to say.