Compile-Time Evaluation

The most common confusion in this area is treating constexpr as a promise. It is not: constexpr on a function means "this function is *eligible* to be evaluated at compile time, and there exists at least one set of arguments for which it can be". Call it with a run-time value and it is an ordinary function. That permissiveness is deliberate — it lets one definition serve both worlds — and it is why a constexpr function can silently end up running at startup instead of never running at all.

C++20 added the two keywords that turn the permission into a guarantee, in each of the two directions people actually wanted. consteval means the function may *only* be called in a constant expression; a run-time call is a compile error, which is what you want for a function that exists to generate something. constinit says nothing about when a function runs, but guarantees a variable is initialised at compile time — its purpose is to eliminate dynamic initialisation, and with it the static initialisation order fiasco, without making the variable const.

Rust draws the line in a third place. A const fn may be called in a constant context and is checked against the subset at definition; the subset itself has grown release by release as more of the language became const-evaluable. Zig collapses the distinction entirely: comptime marks an expression, a parameter or a block to be evaluated during compilation, and the same evaluator that folds arithmetic is also the language's generics mechanism — a generic function is one that takes a comptime type parameter.

The point of all of it is a transfer: work that would have happened once per process start, or once per call, happens once per build instead. A lookup table computed by a loop at startup becomes a blob in the read-only data section. A parsed format string becomes a set of already-selected branches. A checksum over a constant becomes a literal.

What is bought is real but narrower than it looks. The saving is startup time and, for tables, the ability for the linker and loader to share the pages, which matters most where processes are short-lived and never amortise anything — see [[compile-time-vs-runtime]]. It is *not* generally a throughput win, because a good optimizer would fold much of this anyway under [[constant-folding]] and [[partial-evaluation]]. The difference is that constant evaluation is guaranteed and diagnosable, whereas folding is a best effort the compiler is entitled to skip.

And there is one thing constant evaluation can do that no optimizer may: produce a value the *type system* needs. An array bound, a template argument, a static_assert condition, a Zig type — none of those can wait for the optimizer, because the program cannot be checked without them. That is the capability, as opposed to the performance argument, and it is the reason the feature exists at all.

C++ arrived at compile-time computation twice, from two directions, and kept both. Templates were discovered to be Turing-complete and became a metaprogramming language by accident, with types as values and recursion as iteration; constexpr was then added as a way to write compile-time code that looks like ordinary code. The two systems have different syntax, different capabilities and different error messages, and every C++ programmer eventually has to know both.

Zig starts from the other end. There is one evaluator, and comptime marks what runs in it. A generic data structure is a function that takes a comptime type parameter and returns a type — ordinary code, ordinary control flow, ordinary debugging, evaluated during compilation. There is no second language, so there is no second set of error messages, and a compile-time function can be read by anyone who can read the run-time one.

The cost is that the boundary between the two worlds is now everywhere rather than in a few marked places, and errors from the evaluator are about *your* code executing rather than about a type not satisfying a constraint. It is a genuinely different trade rather than a strictly better one — and it is the same trade [[partial-evaluation]] describes in general terms, adopted as the organising principle of a language.

The obvious costs are build time and compiler complexity. Build time, because the interpreter is slower than the compiled code would have been by a factor that can reach thousands, and it runs on every build until an incremental system caches the result. Compiler complexity, because the compiler now contains a second implementation of the language's semantics, with its own object model and lifetime tracking, and every language feature must be considered twice.

The unexpected cost is agreement. The constant evaluator runs on the *host* machine; the generated code runs on the *target*. Every value the evaluator produces must be the value the target would have produced — same integer width, same signedness, same floating-point rounding, same size_t, same endianness for anything that gets serialised. Compilers therefore emulate target arithmetic rather than using the host's, and the places where that emulation has historically been imperfect are exactly the places cross-compiled binaries have differed from native ones. This is invisible until you cross-compile, and then it is a bug with no good symptom.

Then there is debuggability. There is no debugger for the constant evaluator. You cannot set a breakpoint in a consteval function; the tools are static_assert, and in C++ a deliberate compile error that prints the value you wanted to see. Zig has @compileLog, Rust has const panics with messages. All of them are printf debugging with a slow edit-compile loop, and that is the state of the art.