4 ms·

We aren't talking about just compile time function evaluation of ConstExpressions. C++ had that all the way back in C++11, and many compilers were doing CTFE lo

by phire 1y ago

We aren't talking about just compile time function evaluation of ConstExpressions. C++ had that all the way back in C++11, and many compilers were doing CTFE long before that as an optimisation (but as a programmer you couldn't really control when that would happen) Compilers are always allowed to CTFE than what the C++ standard specifies, many do. The standard is just moving the lower bar for what all compilers must now evaluate at compile time, and what c++ programmer may expect from all compilers. Since C++11, they have been massively extending the subset of the language that can be evaluated at compile time. C++14 allowed compiletime evaluation of loops and conditionals, along with local variables. C++20 allowed CTFE functions to do memory allocation (as long as it was also freed) along with calling object constructors/deconstructors. The main new thing in C++26 is the ability to do CTFE placement new, which is something I remember missing the last time I tried to do fancy C++ stuff. Along with marking large chunks of the standard library as constexpr.

JonChesterfield 1y ago
It has been a very exciting fifteen years. As a minor counter argument, other languages will let you run any code at compile time. Because it's code. And it can run whenever you want. C++ has that too I suppose, you just have to weave some of your control flow through cmake.
WalterBright 1y ago
Function calls, loops, conditionals, local variables, memory allocation (via new), constructors/destructors, etc., were all there in D2007.
- jcelerier 1y ago
  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) ?
  - WalterBright 1y ago
    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

by phire 1y ago

JonChesterfield 1y ago

It has been a very exciting fifteen years. As a minor counter argument, other languages will let you run any code at compile time. Because it's code. And it can run whenever you want. C++ has that too I suppose, you just have to weave some of your control flow through cmake.

WalterBright 1y ago

Function calls, loops, conditionals, local variables, memory allocation (via new), constructors/destructors, etc., were all there in D2007.

jcelerier 1y ago
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) ?
- WalterBright 1y ago
  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