checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 4:56 AM, Daniel Murphy wrote:
>> "Artur Skawina via Digitalmars-d"  wrote in message
>> news:mailman.217.1406713015.16021.digitalmars-d at puremagic.com...
>>
>>> `assert` is for *verifying* assumptions. It must not allow them
>>> to leak/escape. Otherwise a single not-100%-correct assert could
>>> defeat critical runtime checks.
>>
>> All you're saying is you want them to have different names, not that it
>> can't work the way Walter and I have described.  If your assertions are
>> invalid and you're compiling with -release, the compiler is free to
>> generate invalid code.  -release is dangerous.  -release is telling the
>> compiler that the code you wrote is correct,  and it can rely on it to
>> be correct.
>
> Exactly! -- Andrei

This just moves the issue around and gives another term a non-obvious 
meaning (the 'release' switch, which is not called e.g. 
'unsafeAssumeCorrect'. Which is still confusing, because it purports to 
keep memory safety intact in @safe code by not disabling array bounds 
checks by default). This is the very topic of this discussion: some 
people get confused when they are assumed to use standard terms with 
non-standard meanings. I was objecting to the apparent attitude that 
this is entirely the fault of the one who gets confused, or that it is 
symptomatic for lack of understanding of concepts.

I mean, we have at least:

some terms with whacky meanings for an outsider:
'release' which does not relate to a released code version and which is 
not in contrast to 'debug'.
'const' which does not relate to being a constant.
'enum' which does not denote enumeration in many contexts where it is used.
'in' which does not only check for membership but rather returns a 
pointer to that member.
'lazy', which denotes pass by name instead of pass by need.
'pure' which denies access to mutable static variables and IO.
... (some more easily debatable ones removed)


some terms with inconsistent meanings:
'alias': alias declarations and alias parameters are notably distinct: 
while I can alias a built-in type to a symbol, I cannot pass it by 
alias. The following fails:

template T(alias a){ enum T=2; }
pragma(msg, T!string);


(Before debate ensues: I am completely aware of what each of the above 
actually mean and do.)

To me, the apt response to a relative newcomer who gets confused by one 
of those or something like them, especially when used without quotation 
marks, is not at all similar to "You're misunderstanding and misusing 
this feature, stop making noise."