checkedint call removal

[Artur Skawina via Digitalmars-d]

On 08/03/14 06:29, Kapps via Digitalmars-d wrote:
> Not all bugs are equal; an assertion being false means a bug exists, but optimizing based off of this allows much more severe bugs to exist. 

Yes.

Giving a new meaning to `assert` would also affect how it's used.
Asserts would be used not only to check and document assumptions, but
also to enable certain optimizations. This would add a new source of
bugs. A harmless i-think-this-is-always-true assert would be
indistinguishable from a potentially dangerous one. The former kind
does not really need much attention, the latter requires special care
and needs to be looked after even when it's not failing.


> Keep the current behaviour of -release disabling asserts, then add a new -assumeasserts or -Oassert 

The problem with this is that it introduces a new dialect in which `assert`
has a different meaning. If parts of a program are (or were) independently
developed by different teams, one using asserts the traditional way (for
debugging) and another using them aggressively to expose every optimization
opportunity, then the debugging asserts which were supposed to be harmless
will be reinterpreted. Effectively you would always have to assume that
assert==assume. So a compiler switch wouldn't really improve the situation.

artur