checkedint call removal

[Daniel Gibson via Digitalmars-d]

Am 31.07.2014 22:57, schrieb Andrei Alexandrescu:
> On 7/31/14, 12:37 PM, Daniel Gibson wrote:
>>
>> This thread however shows that many D users (who probably have more D
>> experience than myself) are not aware that assert() may influence
>> optimization and would prefer to have separate syntax to tell the
>> optimizer what values he can expect.
>
> Yah, I think that's a good outcome. We must document assert better. --
> Andrei

You should have done so 10 years ago.. experienced D coders (that don't 
follow this discussion) probably won't look up what exactly assert() 
does again and and code will silently break in subtle ways once the 
optimizer uses assert()


But if you (as in "the D language implementors") *really* decide to 
stick to this unexpected meaning of assert(), you should indeed document 
this as soon as a proper definition of what assert() does and might do 
in the future, when enforce() vs assert() should be used.

Maybe, besides enforce() and assert() there could be a check() that:
* returns true if the condition is true
* throws an exception in debug mode if the condition is false
* returns false in release mode if the condition is false
could be introduced.
It could be used like

if(check(x !is null, "x must not be null")) {
	// .. do something with x ..
}

to cater the usecase of "in debugmode I want to know about this 
problem/behavior immediately to debug it, but in releasemode I want to 
handle it gracefully".

Cheers,
Daniel