4 ms·
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 fo
by 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 agoTo summarize: 1. https://github.com/ziglang/zig/issues/1291 https://github.com/ziglang/zig/issues/1291 2. wrong 3. wrong
- WalterBright 4y agoSince you wrote Zig, I'll defer to you on it.
- marler8997 4y agoD'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.
- gallier2 4y ago<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.