I don't think that's the same thing (rather, it's more like ordinary Zig variables in code that's evaluated at compile-time), as there's no arbitrary mixing of compile-time and runtime computation. Again, compare with https://ziglang.org/documentation/master/#Case-Study-print-i...
Anyway, I found this article that concludes that D's compile time evaluation is equivalent in power to Zig's, although it also doesn't cover how comptime variables can be used in Zig: https://renato.athaydes.com/posts/comptime-programming
However, as I've said many times, knowing about the theoretical power of partial evaluation, what excites me in Zig isn't what comptime can do (although I am impressed with the syntactic elegance of the mechanism) but how it is used to avoid adding other features.
A phone with a touchscreen is evolutionary; a phone without a keypad is revolutionary. The revolution is in the unique experience of using "just comptime" for many things.
It is, of course, a tradeoff, and whether or not that tradeoff is "good" remains to be seen, but I think this design is one of the most novel designs in programming languages in many, many years.
A comptime variable in D would look like:
Since an enum initialization is a ConstExpression, it's initialization must be evaluated at compile time.A comptime function parameter in D looks like:
where the first parameter list consists of compile time parameters, and the second the runtime parameters.D does not have a switch-over-types statement, but the equivalent can be done with a sequence of static-if statements:
Static If is always evaluated at compile time. The IsExpression does pattern matching on types.