Integer overflow and underflow semantics?

[via Digitalmars-d]

On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via 
Digitalmars-d wrote:

> For D that is not possible -- if an expression is valid at 
> run-time
> then it should be valid at compile-time (and obviously yield 
> the same
> value). Making this aspect of CT evaluation special would make 
> CTFE
> much less useful and add complexity to the language for very 
> little gain.

CT and runtime give different results for floats.
Overflow in the end result without explicit truncation should be 
considered a bug. Bugs can yield different results.

Overflow checks on add/sub expressions mess up reordering 
optimizations. You only care about overflows in the end result.

Exact, truncating, masking/wrapping or saturating math results 
should be explicit. (It is a flaw to use the same div operator 
for floats and ints.) It should be the programmers resposibility 
to provide the proofs or turn on extra precision in debug mode.

Turning off reordering optimizations and add checks ought to be 
the rare case for both ints and floats.

Ideally all ctfe would be done as real intervals with rational 
bounds, then checked against the specified precision of the end 
result (or numerically solving the whole expression to the 
specified precision).

> Trying to handle just a subset of the problem would make things 
> even
> worse -- /some/ code would not be CTFE-able and /some/ 
> overflows wouldn't
> be caught.
>
>    int f(int a, int b) { return a*b; }
>    enum v = f(100_000, 100_000);

NUMBER f(NUMBER a, NUMBER b) ...