checkedint call removal

[Timon Gehr via Digitalmars-d]

On 07/30/2014 07:56 PM, Andrei Alexandrescu wrote:
> 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:
>> ...
>
>> 'lazy', which denotes pass by name instead of pass by need.
>
> It's not pass by name.
> ...

How so? Is it about failure to allocate a closure?

>> 'pure' which denies access to mutable static variables and IO.
>
> That's the consequence of functional purity as defined by D.

Somewhat debatable, but unworthy of debate.

> I see nothing wrong with it.
> ...

Luckily, that wasn't the claim. :)

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

Probably. I never wrote it down in an ordered fashion.

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

I think there was no such case (yet), only an unsuccessful attempt to 
clear up a misunderstanding based on terminology.

> How do you think you'll fare with newcomers?
> ...

Hopefully, awesomely. Much less preconceptions.

>
> Andrei
>