Jule Comptime: Moving Fixed Computation Into the Build

The problem: fixed data that still costs work at runtime

A protocol decoder often needs a table mapping numeric message codes to handlers. Those codes never change while the process runs, yet the table is usually either hand-written in source or parsed from JSON during startup. The first option is tedious to maintain; the second adds parsing time, allocation, and failure paths to every launch.

Jule's comptime feature offers a third option: evaluate selected functions during compilation and keep their results as constants. The useful takeaway is narrower than the word "metaprogramming" suggests. Comptime is for computations whose inputs are fixed in the source and whose output should be checked before the program runs.

What Jule's comptime guarantees, and where it stops

Marking a function or variable with comptime makes its evaluation a compile-time requirement. The compiler runs the code during type checking and uses the result as a constant or type-level value. If evaluation fails, the build fails; there is no runtime fallback.

That guarantee comes with a sandbox. Compile-time code can branch, loop, allocate, and call other comptime functions. It cannot make foreign-function-interface calls, execute inline assembly, or use operating-system services such as file I/O, networking, or clocks. A comptime function also cannot capture a runtime value, so it cannot produce a closure over data that only exists after startup.

Generic parameters are known at compile time, which lets comptime functions validate constraints or specialize behavior for a type before code generation. The resulting value can feed an array size, an enum discriminant, or a generic argument.

To keep a bad loop from hanging the compiler, evaluation is bounded by a step limit. The documented default is on the order of one million steps, and the limit can be raised with a compiler option. Confirm the exact default, option spelling, and diagnostic wording for the Jule release you install; these details are version-sensitive.

Worked example: generate a dispatch table during compilation

Suppose four message codes need to map to small integer identifiers. The table is fixed, but writing it by hand invites mistakes: a missing entry or a wrong index becomes a runtime bug.

comptime fn build_dispatch_table() -> [u16]u16 {
    let codes = [u16]u16{0x0001, 0x0010, 0x0011, 0x0100}

    let mut table = [u16]u16{}
    for i, code in codes {
        table[code] = u16(i)
    }
    return table
}

const DISPATCH_TABLE = build_dispatch_table()

fn dispatch(code: u16) -> Option[u16] {
    if code >= DISPATCH_TABLE.len() {
        return None
    }
    return Some(DISPATCH_TABLE[code])
}

Two details matter. First, the table is a compile-time constant, so the runtime path is an array read rather than a parse. Second, the lookup is still bounds-checked at runtime unless the compiler can prove the range; the constant removes the cost of building the table, not every safety check.

The array-literal and iteration syntax above follows the usual Jule shape, but check the exact forms in the language reference for your version before copying them into a project.

Verify the result instead of assuming it

1. Run jule init myproto in a writable directory you own, then cd myproto. Initialization needs no special privileges.
2. Add the example to a source file and run jule build --comptime-trace from the project root. Look for trace lines showing the comptime function being evaluated. If the flag is rejected, check jule build --help for the current spelling.
3. Build normally and inspect the output with objdump -s -j .rodata <path-to-binary>, which requires binutils. The table may be inlined or renamed, so the absence of a readable symbol is not proof that evaluation failed.
4. Change one code in the source and rebuild. The trace should show the function running again; that is expected because results are not cached between builds.

When comptime is the wrong tool

Approach	Use when	Cost
Runtime computation	The input is unknown until the process starts	Parsing and allocation on every run
Jule comptime	The input is fixed in source and the result should be validated by the compiler	Re-evaluated on each build; bounded by the step limit
External build-time generator	Generation is large, slow, or needs tools the compiler sandbox cannot reach	Extra tooling and generated source to review

Three limits shape that decision. There is no incremental caching, so a heavy comptime program can slow every edit-build cycle. Debugging is indirect: no interactive debugger attaches to the evaluator, so deliberate panic messages and trace output are the practical tools. And each distinct comptime-specialized generic instantiation can produce its own copy of code, which can increase binary size across large type sets.

Cross-compilation adds another subtlety. The evaluator runs on the machine performing the build, while target-specific builtins such as pointer size or byte order are intended to describe the compilation target. That makes host and target values easy to confuse. Verify the behavior with a deliberately failing assertion before relying on it, and confirm the target name and toolchain requirements for your installed compiler.

A conservative first experiment

1. Start with one small function whose result is a constant you can inspect by printing it or by checking the built binary.
2. Add a deliberate error path, such as rejecting a duplicate code, and confirm the compiler reports it instead of shipping the table.
3. Measure build time before and after adding the comptime function. If the increase is noticeable, move the work to an external generator rather than raising the step limit.
4. Check the current language reference and compiler help for the exact syntax, step-limit option, and trace flag in your installed version.

Comptime earns its place when a small, fixed computation replaces a runtime cost or a hand-maintained table. Keep it that size. If the computation grows into a build system, a separate generator with reviewable output is the clearer engineering choice.