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