4 ms·

> 1. It enables a killer feature - CTFE that can allocate memory. C++ doesn't do that. Zig doesn't do that. As anything but a compiler expert, I don't understa

• WalterBright 4y ago
  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.
  • eatonphil 4y ago
    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?
    • WalterBright 4y ago
      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 https://dlang.org/spec/function.html#interpretation
      • leni536 4y ago
        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.
      • kristoff_it 4y ago
        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.
        • AndyKelley 4y ago
          To summarize: 1. https://github.com/ziglang/zig/issues/1291 https://github.com/ziglang/zig/issues/1291 2. wrong 3. wrong
          • WalterBright 4y ago
            Since you wrote Zig, I'll defer to you on it.
        • marler8997 4y ago
          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.
• leni536 4y ago
  ...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.