The CTFE interpreter knows what "new" does, and just calls the compiler's "new" function to allocate memory. If the user wrote their own custom allocator, then the CTFE would have to interpret that, which is kind of a big mess.

Dumb question: what's the difference between CTFE (I haven't heard of that term before) and Zig's comptime and C++'s constant expressions?

1. Zig and C++ cannot allocate memory for CTFE.

2. Zig and C++ require any code to be run at compile time to be specially marked (comptime, constexpr). D will run any code that appears in a const-expression at compile time.

3. Zig and C++ require that if a function is to be used for CTFE, the entire function must be compatible with CTFE. D only requires the path taken through the function to be compatible with CTFE. D even has a `__ctfe` pseudo-variable that can be used to branch within a function to compile-time and run-time paths.

https://dlang.org/spec/function.html#interpretation

Point 2 is not really true for Zig, functions don't need to be specially marked to be callable at compile time. The comptime keyword is sometimes required to force compile time resolution (Zig currently doesn't eagerly try to resolve function calls at compile time), but in any compile-time-only context not even that is necessary, like so:

   fn double(n: usize) usize {
      return 2*n;
   }
   
   const MyArrType = [double(5)]u8;

Similarly, point 3 is not really true either, what matters in Zig as well is the path that the function took during evaluation.

  const std = @import("std");

  fn double(n: usize) usize {
    if (n % 2 == 0) {
        std.debug.print("even!", .{});
    }

    return 2*n;
  }

  const MyArrayType = [double(5)]u8; // this works
  //const Bad = [double(6)]u8; // this will fail to compile

You are right about allocation not working during comptime evaluation at the moment, but this is not a final design decision, just the current status quo.

D's actually worse than Zig in regard to point 3. Kristoff's example demonstrates why. In D you would have to change the "if" to a "static if", D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.

The bigger issue D has with this example is that normal parameters are always runtime. If you wanted this to work in D you would need to implement 2 versions of "double", one that takes n as a template parameter and one that takes it as a runtime parameter. D keeps comptime and runtime parameters separate, making comptime-knowness a "parameter color" which in practice means having to implement things twice if you want it at comptime and often in different ways. There are some things that can work with both but it's small subset of both.

<i>D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.</i>

WRONG. if in a CTFE function works without problems. static if has nothing to do with CTFE. static if is conceptually a beefed up proper #ifdef/#endif.

The biggest issue D has is all the FUD and misconceptions that are propagated about it.

To summarize:

1. https://github.com/ziglang/zig/issues/1291

2. wrong

3. wrong

Since you wrote Zig, I'll defer to you on it.

C++20 has limited support for allocating memory at compile time. The allocations can't be leaked from the constant expression context, so that limits usefulness.

There are proposals to extend it, but there are some non-trivial const correctness issues to be solved there, AFAIK.

...and if you want all of CTFE, allocate memory and nogc at the same time, then yoh are screwed.

C++20 has limited support for allocating at compile time.