checkedint call removal

[Artur Skawina via Digitalmars-d]

On 08/03/14 17:06, Walter Bright via Digitalmars-d wrote:
> On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
>> There's nothing wrong with `assume`, it's very useful for optimizations.
>> But it's too dangerous to tack `assume` onto `assert`. If they are kept
>> separate then it's at least possible to carefully audit every 'assume'.
>> People *will* use them for micro-optimizations, and they *will* make
>> mistakes.
> 
> This seems contradictory. You say it is fine to have assume affect optimization, i.e. insert bugs if the assumes are wrong, but not fine to check at runtime that the assumes are correct?

I'm saying there's nothing wrong with having an assume(-like) directive;
by default `assume` should of course check the condition at RT just like
`assert` does [1].

I'm against _redefining_ `assert` to mean `assume`. In practice there will
always be a possibility of an assert failing at RT due to eg a different
environment or inputs[2]. If programs always were perfect and absolutely
bug-free, asserts and diagnostics would never be required at all...

Do you really think that it is unreasonable to expect that, in a language
called *D*, a very well known decades old C concept isn't redefined?
That wouldn't be appropriate even for a language called "Mars"...

Of course everybody initially expects that an 'assert' in D acts like
the C equivalent. There isn't anything in the "spec" (ie dlang.org) that
even hints at D's assert being different. ("[...] if the result is false,
an AssertError is thrown. If the result is true, then no exception is
thrown.[...]"). I just looked at the "contracts" page for the first time
ever, and found this: "assert in function bodies works by throwing an
AssertError, which can be caught and handled". That could reasonably be
interpreted to mean that a failing assertion in D still leaves the program
in a well defined valid (!) state.

Most people who are already aware of `assert` will know a definition like
this one: http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html
"assert - insert program diagnostics [...] The assert() macro shall insert
diagnostics into programs".
Nobody expects that disabling diagnostics introduces undefined behavior.
Hence, slightly inaccurate or not 100% up-to-date asserts are not considered
a real problem. And they are not a problem. Except in D?

artur

[1] An `__assume` that never checks at RT would also be useful for low-level
    code, where failure is not an option.

[2] Asserts are not for /directly/ validating inputs, yes, but inputs are
    often necessary to get the program to an invalid state.