checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/29/2014 10:52 PM, Walter Bright wrote:
> On 7/29/2014 1:07 PM, Timon Gehr wrote:
>> On 07/29/2014 03:07 AM, Walter Bright wrote:
>>> On 7/28/2014 1:49 PM, "Ola Fosheim Grøstad"
>>> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>>>> You might want to assert() that you have enough headroom in a
>>>> statically
>>>> allocated buffer when testing. Say you assert that the buffer is never
>>>> more than
>>>> 50% full for normal loads. You obviously don't want the -release build
>>>> to make
>>>> such an assumption!
>>>
>>> You're misunderstanding
>>
>> He still has a point. This is just another case of the keyword not
>> matching the
>> semantics very well. It would be more aptly named 'assume' instead of
>> 'assert'
>> (and be un- at safe if release mode is to trust it unconditionally.)
>
> I find this splitting of hares between assume and assert to be entirely
> meaningless.
> ...

They are dual concepts. Assert demands a property to hold, assume 
provides a property that holds.

_According to the previous posts in this discussion_, in release mode, 
'assert' provides a property that holds without any demands.

All I was saying is that

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.

>
>>> and misusing assert.
>>>
>>> 'assume' is completely redundant with 'assert'.
>> Only if you assume _a priori_ the program to be correct.
> ...
>
>>> To have different debug builds, use debug statements.
>> 'version(assert) assert' is a better match here, because if one uses
>> 'debug
>> assert', there is the possibility of passing both -debug and -release
>> and get
>> the undesired behaviour.
>
> That cure sounds worse than the (supposed) problem.
> ...

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

(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.

BTW what about the following gem?

version(assert){}
else int x=2;
assert({
     static if(is(typeof(x))) enum e=loopForever();
     return someExpression;
}());

Should I expect it to stall compilation starting from a certain 
optimization level in -release mode, or what should be going on here?)

>
> I still have problems convincing people that assert is not to be used to
> validate user input. Howinell is there any hope of getting anyone to
> understand all this fine-grained hare-splitting? Heck, I don't see any
> useful difference between assert and assume.

I hope this post cleared it up a little.