checkedint call removal

[Walter Bright via Digitalmars-d]

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.


>> and misusing assert.
>>
>> 'assume' is completely redundant with 'assert'.
> Only if you assume _a priori_ the program to be correct.

I've read yours and Ola's explanations of the difference, and I still can't 
discern any difference, other than the spelling.


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