checkedint call removal

[Artur Skawina via Digitalmars-d]

On 07/30/14 13:56, Daniel Murphy via Digitalmars-d 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,

"D - the language that redefines commonly used and universally
understood terms and concepts"?

> not that it can't work the way Walter and I have described.

Possible != sane.

The main problem isn't even the terminology; it's the consequences
wrt safety and correctness.

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

Consider a service/program that handles user supplied data. It
uses several third-party libs, one for parsing and validating the
inputs, another for some other processing/communication, etc.
One is carefully written with security in mind and can safely
deal with every possible valid or invalid input. Another was not
considered security sensitive and designed to work on valid data.
The input requirements are just documented and only checked via
asserts. Now the programmer implementing that service only needs
to make a single mistake, so that an invalid (or just unexpected)
input is passed to the less hardened lib. In a production setting
the asserts are not present, but the assumptions have leaked to
the other libs, and some of the carefully written checks have been
statically eliminated by the compiler. Code that was perfectly safe
gained an invisible (!) security hole, because of an innocent
looking assert statement in a different code base.

artur