checkedint call removal

[Andrei Alexandrescu via Digitalmars-d]

On 7/30/14, 9:31 AM, Timon Gehr wrote:
> 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'.

Well to me "-release" is "I assume my program is correct, generate the 
fastest code for it".

> 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'm not sure what would be the standard misused term in this case.

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

Yeah, it's a sensible point. I don't like that either, but it's a minor 
annoyance at most.

> 'const' which does not relate to being a constant.

"Like C++ const, but transitive".

> 'enum' which does not denote enumeration in many contexts where it is used.

Sensible point, but in our use at Facebook I noticed engineers picking 
it up without a hitch.

> 'in' which does not only check for membership but rather returns a
> pointer to that member.

It's conveniently terse.

> 'lazy', which denotes pass by name instead of pass by need.

It's not pass by name.

> 'pure' which denies access to mutable static variables and IO.

That's the consequence of functional purity as defined by D. I see 
nothing wrong with it.

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

Agreed.

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

I think you got a point there but if you searched any programming 
language in its pockets you're liable to find a bunch of similar lint. 
It's the way it goes - there's a need to maximize expressiveness while 
keeping vocabulary and grammatical constructs low. Few of these items 
are near the top of my list of issues in D, and I think the same goes 
for your list.

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

Consider this: after considerable effort you are failing to explain your 
case for "assume" to the language creators. How do you think you'll fare 
with newcomers?


Andrei