checkedint call removal

[via Digitalmars-d]

On Monday, 28 July 2014 at 13:50:29 UTC, Daniel Murphy wrote:
> Yes, writing code wrong can result in the wrong thing 
> happening.  A non-release build will always retain the asserts.

No, writing wrong code is one thing.

Having a single typo in a constraint-test cause memory unsafety 
undetected is a disaster. And many such typos _will_ go 
undetected.

Let's say you want to test "divisor >= 0", but end up with 
"divisor != 0" => division_by_zero failure even if the code is 
correct.

Adding assert() should increase quality, not decrease it. Adding 
asserts will increase the probability of wrong constraints 
entering the codebase. That means with the regime indicated here 
you should write as few assert() statements as possible.

>> Assert() are useful debugging tools, but not a codegen 
>> feature. A good debugger could allow you to turn them on/off 
>> or let you continue after hitting one. That's useful.
>
> If this is what you want you shouldn't be using assert.  This 
> is not what assert means in D.

Where in the spec does it say that assert is a tool for 
specifying optimization constraints?

That would be a disaster.