A big discussion item in constexpr in C++ was evaluation of floating-point at compile-time. Because depending on your current running CPU flags, you can easily end up in a case where a function do not give the same result whether at run-time vs at compile-time, confusing users. How does that work in D (and for that matters, any other language with compile-time evaluation) ?

That's a great point.

Here's the thing - that cannot be fixed. Consider the x87 FPU. It does all computations to 80 bits, regardless of how you set the flags for it. The only way to get it to round to double/float is to write the value out to memory, then read it back in.

Java tried this fix. The result was a catastrophe, because it was terribly slow. They backed out of it.

The problem has since faded away as the X86_64 has XMM registers for float/double math.

C still allows float to be done in double precision.

D evaluates CTFE in the precision specified by the code.

More to the point, constexpr does supply something D doesn't do. Whether D runs a calculation at compile time or run time is 100% up to the programmer. The trigger is a Constant-Expression in the grammar, a keyword is not required.

BTW, D's ImportC C compiler does the same thing - a constant expression in the grammar is always evaluted at compile time! (Whereas other C compilers just issue an error.)

    int sum(int a, int b) { return a + b; }
    _Static_assert(sum(1,2) == 3, "message");  // works in ImportC
    _Static_assert(sum(1,2) == 3, "message");  // gcc error: expression in static assertion is not constant