comptime

    Compile-time parameters is how Zig implements generics. It is compile-time duck typing.

    test.zig

    In Zig, types are first-class citizens. They can be assigned to variables, passed as parameters to functions, and returned from functions. However, they can only be used in expressions which are known at compile-time, which is why the parameter in the above snippet must be marked with comptime.

    A comptime parameter means that:

    • At the callsite, the value must be known at compile-time, or it is a compile error.
    • In the function definition, the value is known at compile-time.

    For example, if we were to introduce another function to the above snippet:

    test.zig

    1. fn max(comptime T: type, a: T, b: T) T {
    2.     return if (a > b) a else b;
    3. }
    4. test "try to pass a runtime type" {
    5.     foo(false);
    6. }
    7. fn foo(condition: bool) void {
    8.     const result = max(
    9.         if (condition) f32 else u64,
    10.         1234,
    11.         5678);
    12.     _ = result;
    13. }

    Shell

    1. $ zig test test.zig
    2. ./docgen_tmp/test.zig:9:9: error: values of type 'type' must be comptime known
    3.         if (condition) f32 else u64,
    4.         ^

    This is an error because the programmer attempted to pass a value only known at run-time to a function which expects a value known at compile-time.

    Another way to get an error is if we pass a type that violates the type checker when the function is analyzed. This is what it means to have compile-time duck typing.

    For example:

    test.zig

    1. fn max(comptime T: type, a: T, b: T) T {
    2.     return if (a > b) a else b;
    3. }
    4. test "try to compare bools" {
    5.     _ = max(bool, true, false);
    6. }

    Shell

    1. $ zig test test.zig
    2. ./docgen_tmp/test.zig:2:18: error: operator not allowed for type 'bool'
    3.     return if (a > b) a else b;
    4.                  ^
    5. ./docgen_tmp/test.zig:5:12: note: called from here
    6.     _ = max(bool, true, false);
    7.            ^
    8. ./docgen_tmp/test.zig:4:29: note: called from here
    9. test "try to compare bools" {
    10.                             ^

    On the flip side, inside the function definition with the comptime parameter, the value is known at compile-time. This means that we actually could make this work for the bool type if we wanted to:

    comptime_max_with_bool.zig

    1. fn max(comptime T: type, a: T, b: T) T {
    2.     if (T == bool) {
    3.         return a or b;
    4.     } else if (a > b) {
    5.         return a;
    6.     } else {
    7.         return b;
    8.     }
    9. }
    10. test "try to compare bools" {
    11.     try @import("std").testing.expect(max(bool, false, true) == true);
    12. }

    Shell

    1. $ zig test comptime_max_with_bool.zig
    2. 1/1 test "try to compare bools"... OK
    3. All 1 tests passed.

    This works because Zig implicitly inlines if expressions when the condition is known at compile-time, and the compiler guarantees that it will skip analysis of the branch not taken.

    This means that the actual function generated for max in this situation looks like this:

    test.zig

    1. fn max(a: bool, b: bool) bool {
    2.     return a or b;
    3. }

    All the code that dealt with compile-time known values is eliminated and we are left with only the necessary run-time code to accomplish the task.

    This works the same way for switch expressions - they are implicitly inlined when the target expression is compile-time known.

    In Zig, the programmer can label variables as comptime. This guarantees to the compiler that every load and store of the variable is performed at compile-time. Any violation of this results in a compile error.

    This combined with the fact that we can inline loops allows us to write a function which is partially evaluated at compile-time and partially at run-time.

    For example:

    comptime_vars.zig

    1. const expect = @import("std").testing.expect;
    3. const CmdFn = struct {
    4.     name: []const u8,
    5.     func: fn(i32) i32,
    6. };
    8. const cmd_fns = [_]CmdFn{
    9.     CmdFn {.name = "one", .func = one},
    10.     CmdFn {.name = "two", .func = two},
    11.     CmdFn {.name = "three", .func = three},
    12. };
    13. fn one(value: i32) i32 { return value + 1; }
    14. fn two(value: i32) i32 { return value + 2; }
    15. fn three(value: i32) i32 { return value + 3; }
    17. fn performFn(comptime prefix_char: u8, start_value: i32) i32 {
    18.     var result: i32 = start_value;
    19.     comptime var i = 0;
    20.     inline while (i < cmd_fns.len) : (i += 1) {
    21.         if (cmd_fns[i].name[0] == prefix_char) {
    22.             result = cmd_fns[i].func(result);
    23.         }
    24.     }
    25.     return result;
    26. }
    28. test "perform fn" {
    29.     try expect(performFn('t', 1) == 6);
    30.     try expect(performFn('o', 0) == 1);
    31.     try expect(performFn('w', 99) == 99);
    32. }

    Shell

    1. $ zig test comptime_vars.zig
    2. 1/1 test "perform fn"... OK
    3. All 1 tests passed.

    This example is a bit contrived, because the compile-time evaluation component is unnecessary; this code would work fine if it was all done at run-time. But it does end up generating different code. In this example, the function performFn is generated three different times, for the different values of prefix_char provided:

    performFn_1

    1. // From the line:
    2. // expect(performFn('t', 1) == 6);
    3. fn performFn(start_value: i32) i32 {
    4.     var result: i32 = start_value;
    5.     result = two(result);
    6.     result = three(result);
    7.     return result;
    8. }
    1. // From the line:
    2. // expect(performFn('o', 0) == 1);
    3. fn performFn(start_value: i32) i32 {
    4.     var result: i32 = start_value;
    5.     result = one(result);
    6.     return result;
    7. }

    performFn_3

    Note that this happens even in a debug build; in a release build these generated functions still pass through rigorous LLVM optimizations. The important thing to note, however, is not that this is a way to write more optimized code, but that it is a way to make sure that what should happen at compile-time, does happen at compile-time. This catches more errors and as demonstrated later in this article, allows expressiveness that in other languages requires using macros, generated code, or a preprocessor to accomplish.

    In Zig, it matters whether a given expression is known at compile-time or run-time. A programmer can use a comptime expression to guarantee that the expression will be evaluated at compile-time. If this cannot be accomplished, the compiler will emit an error. For example:

    test.zig

    1. extern fn exit() noreturn;
    3. test "foo" {
    4.     comptime {
    5.         exit();
    6.     }
    7. }

    Shell

    1. $ zig test test.zig
    2. ./docgen_tmp/test.zig:5:9: error: unable to evaluate constant expression
    3.         exit();
    4.         ^
    5. ./docgen_tmp/test.zig:5:13: note: referenced here
    6.         exit();
    7.             ^

    It doesn’t make sense that a program could call exit() (or any other external function) at compile-time, so this is a compile error. However, a comptime expression does much more than sometimes cause a compile error.

    Within a comptime expression:

    • All variables are comptime variables.
    • All if, while, for, and switch expressions are evaluated at compile-time, or emit a compile error if this is not possible.
    • All function calls cause the compiler to interpret the function at compile-time, emitting a compile error if the function tries to do something that has global run-time side effects.

    This means that a programmer can create a function which is called both at compile-time and run-time, with no modification to the function required.

    Let’s look at an example:

    fibonacci_recursion.zig

    1. const expect = @import("std").testing.expect;
    3. fn fibonacci(index: u32) u32 {
    4.     if (index < 2) return index;
    5.     return fibonacci(index - 1) + fibonacci(index - 2);
    6. }
    8. test "fibonacci" {
    9.     // test fibonacci at run-time
    10.     try expect(fibonacci(7) == 13);
    12.     // test fibonacci at compile-time
    13.     comptime {
    14.         try expect(fibonacci(7) == 13);
    15.     }
    16. }

    Shell

    1. $ zig test fibonacci_recursion.zig
    2. 1/1 test "fibonacci"... OK
    3. All 1 tests passed.

    Imagine if we had forgotten the base case of the recursive function and tried to run the tests:

    test.zig

    1. const expect = @import("std").testing.expect;
    3. fn fibonacci(index: u32) u32 {
    4.     //if (index < 2) return index;
    5.     return fibonacci(index - 1) + fibonacci(index - 2);
    6. }
    8. test "fibonacci" {
    9.     comptime {
    10.         try expect(fibonacci(7) == 13);
    11.     }
    12. }

    Shell

    1. $ zig test test.zig
    2. ./docgen_tmp/test.zig:5:28: error: operation caused overflow
    3.     return fibonacci(index - 1) + fibonacci(index - 2);
    4.                            ^
    5. ./docgen_tmp/test.zig:5:21: note: called from here
    6.     return fibonacci(index - 1) + fibonacci(index - 2);
    8.     return fibonacci(index - 1) + fibonacci(index - 2);
    9.                     ^
    10. ./docgen_tmp/test.zig:5:21: note: called from here
    11.     return fibonacci(index - 1) + fibonacci(index - 2);
    12.                     ^
    13. ./docgen_tmp/test.zig:5:21: note: called from here
    14.     return fibonacci(index - 1) + fibonacci(index - 2);
    15.                     ^
    16. ./docgen_tmp/test.zig:5:21: note: called from here
    17.     return fibonacci(index - 1) + fibonacci(index - 2);
    18.                     ^
    19. ./docgen_tmp/test.zig:5:21: note: called from here
    20.     return fibonacci(index - 1) + fibonacci(index - 2);
    21.                     ^
    22. ./docgen_tmp/test.zig:5:21: note: called from here
    23.     return fibonacci(index - 1) + fibonacci(index - 2);
    24.                     ^
    25. ./docgen_tmp/test.zig:10:29: note: called from here
    26.         try expect(fibonacci(7) == 13);
    27.                             ^
    28. ./docgen_tmp/test.zig:8:18: note: called from here
    29. test "fibonacci" {
    30.                  ^
    31. ./docgen_tmp/test.zig:5:21: note: referenced here
    32.     return fibonacci(index - 1) + fibonacci(index - 2);
    33.                     ^
    34. ./docgen_tmp/test.zig:10:29: note: referenced here
    35.         try expect(fibonacci(7) == 13);
    36.                             ^

    The compiler produces an error which is a stack trace from trying to evaluate the function at compile-time.

    Luckily, we used an unsigned integer, and so when we tried to subtract 1 from 0, it triggered undefined behavior, which is always a compile error if the compiler knows it happened. But what would have happened if we used a signed integer?

    test.zig

    1. const expect = @import("std").testing.expect;
    3. fn fibonacci(index: i32) i32 {
    4.     //if (index < 2) return index;
    5.     return fibonacci(index - 1) + fibonacci(index - 2);
    6. }
    8. test "fibonacci" {
    9.     comptime {
    10.         try expect(fibonacci(7) == 13);
    11.     }
    12. }

    Shell

    1. $ zig test test.zig
    2. ./docgen_tmp/test.zig:5:21: error: evaluation exceeded 1000 backwards branches
    3.     return fibonacci(index - 1) + fibonacci(index - 2);
    4.                     ^
    5. ./docgen_tmp/test.zig:5:21: note: called from here
    6.     return fibonacci(index - 1) + fibonacci(index - 2);
    7.                     ^
    8. ./docgen_tmp/test.zig:5:21: note: called from here
    9.     return fibonacci(index - 1) + fibonacci(index - 2);
    10.                     ^
    11. ./docgen_tmp/test.zig:5:21: note: called from here
    12.     return fibonacci(index - 1) + fibonacci(index - 2);
    13.                     ^
    14. ./docgen_tmp/test.zig:5:21: note: called from here
    15.     return fibonacci(index - 1) + fibonacci(index - 2);
    16.                     ^
    17. ./docgen_tmp/test.zig:5:21: note: called from here
    18.     return fibonacci(index - 1) + fibonacci(index - 2);
    19.                     ^
    20. ./docgen_tmp/test.zig:5:21: note: called from here
    21.     return fibonacci(index - 1) + fibonacci(index - 2);
    22.                     ^
    23. ./docgen_tmp/test.zig:5:21: note: called from here
    24.     return fibonacci(index - 1) + fibonacci(index - 2);
    25.                     ^
    26. ./docgen_tmp/test.zig:5:21: note: called from here
    27.     return fibonacci(index - 1) + fibonacci(index - 2);
    28.                     ^
    29. ./docgen_tmp/test.zig:5:21: note: called from here
    30.     return fibonacci(index - 1) + fibonacci(index - 2);
    31.                     ^
    32. ./docgen_tmp/test.zig:5:21: note: called from here
    33.     return fibonacci(index - 1) + fibonacci(index - 2);
    34.                     ^
    35. ./docgen_tmp/test.zig:5:21: note: called from here
    36.     return fibonacci(index - 1) + fibonacci(index - 2);
    37.                     ^
    38. ./docgen_tmp/test.zig:10:29: note: referenced here
    39.         try expect(fibonacci(7) == 13);
    40.                             ^

    The compiler noticed that evaluating this function at compile-time took a long time, and thus emitted a compile error and gave up. If the programmer wants to increase the budget for compile-time computation, they can use a built-in function called to change the default number 1000 to something else.

    What if we fix the base case, but put the wrong value in the expect line?

    test.zig

    1. const expect = @import("std").testing.expect;
    3. fn fibonacci(index: i32) i32 {
    4.     if (index < 2) return index;
    5.     return fibonacci(index - 1) + fibonacci(index - 2);
    6. }
    8. test "fibonacci" {
    9.     comptime {
    10.         try expect(fibonacci(7) == 99999);
    11.     }
    12. }

    Shell

    1. $ zig test test.zig
    2. 1/1 test "fibonacci"... test "fibonacci"... FAIL (TestUnexpectedResult)
    3. FAIL (TestUnexpectedResult)
    4. 0 passed; 0 skipped; 1 failed.
    5. error: the following test command failed with exit code 1:
    6. docgen_tmp/zig-cache/o/8e4964e05ddaf866e77360a551b3c05b/test /home/andy/Downloads/zig/build-release/zig

    What happened is Zig started interpreting the expect function with the parameter ok set to false. When the interpreter hit @panic it emitted a compile error because a panic during compile causes a compile error if it is detected at compile-time.

    At container level (outside of any function), all expressions are implicitly comptime expressions. This means that we can use functions to initialize complex static data. For example:

    N_primes.zig

    1. const first_25_primes = firstNPrimes(25);
    2. const sum_of_first_25_primes = sum(&first_25_primes);
    4. fn firstNPrimes(comptime n: usize) [n]i32 {
    5.     var prime_list: [n]i32 = undefined;
    6.     var next_index: usize = 0;
    7.     var test_number: i32 = 2;
    8.     while (next_index < prime_list.len) : (test_number += 1) {
    9.         var test_prime_index: usize = 0;
    10.         var is_prime = true;
    11.         while (test_prime_index < next_index) : (test_prime_index += 1) {
    12.             if (test_number % prime_list[test_prime_index] == 0) {
    13.                 is_prime = false;
    14.                 break;
    15.             }
    16.         }
    17.         if (is_prime) {
    18.             prime_list[next_index] = test_number;
    19.             next_index += 1;
    20.         }
    21.     }
    22.     return prime_list;
    23. }
    25. fn sum(numbers: []const i32) i32 {
    26.     var result: i32 = 0;
    27.     for (numbers) |x| {
    28.         result += x;
    29.     }
    30.     return result;
    31. }
    33. test "variable values" {
    34.     try @import("std").testing.expect(sum_of_first_25_primes == 1060);
    35. }

    Shell

    When we compile this program, Zig generates the constants with the answer pre-computed. Here are the lines from the generated LLVM IR:

    1. @0 = internal unnamed_addr constant [25 x i32] [i32 2, i32 3, i32 5, i32 7, i32 11, i32 13, i32 17, i32 19, i32 23, i32 29, i32 31, i32 37, i32 41, i32 43, i32 47, i32 53, i32 59, i32 61, i32 67, i32 71, i32 73, i32 79, i32 83, i32 89, i32 97]
    2. @1 = internal unnamed_addr constant i32 1060

    Zig uses these capabilities to implement generic data structures without introducing any special-case syntax. If you followed along so far, you may already know how to create a generic data structure.

    Here is an example of a generic List data structure, that we will instantiate with the type i32. In Zig we refer to the type as List(i32).

    test.zig

    1. fn List(comptime T: type) type {
    2.     return struct {
    3.         items: []T,
    4.         len: usize,
    5.     };
    6. }

    That’s it. It’s a function that returns an anonymous struct. For the purposes of error messages and debugging, Zig infers the name "List(i32)" from the function name and parameters invoked when creating the anonymous struct.

    To keep the language small and uniform, all aggregate types in Zig are anonymous. To give a type a name, we assign it to a constant:

    test.zig

    1. const Node = struct {
    2.     next: *Node,
    3.     name: []u8,
    4. };

    This works because all top level declarations are order-independent, and as long as there isn’t an actual infinite regression, values can refer to themselves, directly or indirectly. In this case, Node refers to itself as a pointer, which is not actually an infinite regression, so it works fine.

    Putting all of this together, let’s see how print works in Zig.

    print.zig

    1. const print = @import("std").debug.print;
    3. const a_number: i32 = 1234;
    4. const a_string = "foobar";
    6. pub fn main() void {
    7.     print("here is a string: '{s}' here is a number: {}\n", .{a_string, a_number});
    8. }

    Shell

    1. $ zig build-exe print.zig
    4. here is a string: 'foobar' here is a number: 1234

    Let’s crack open the implementation of this and see how it works:

    poc_print_fn.zig

    1. const Writer = struct {
    2.     /// Calls print and then flushes the buffer.
    3.     pub fn print(self: *Writer, comptime format: []const u8, args: anytype) anyerror!void {
    4.         const State = enum {
    5.             start,
    6.             open_brace,
    7.         };
    9.         comptime var start_index: usize = 0;
    10.         comptime var state = State.start;
    11.         comptime var next_arg: usize = 0;
    13.         inline for (format) |c, i| {
    14.             switch (state) {
    15.                 State.start => switch (c) {
    16.                     '{' => {
    17.                         if (start_index < i) try self.write(format[start_index..i]);
    18.                         state = State.open_brace;
    19.                     },
    20.                     '}' => {
    21.                         if (start_index < i) try self.write(format[start_index..i]);
    22.                         state = State.close_brace;
    23.                     },
    24.                     else => {},
    25.                 },
    26.                 State.open_brace => switch (c) {
    27.                     '{' => {
    28.                         state = State.start;
    29.                         start_index = i;
    30.                     },
    31.                     '}' => {
    32.                         try self.printValue(args[next_arg]);
    33.                         next_arg += 1;
    34.                         state = State.start;
    35.                         start_index = i + 1;
    36.                     },
    37.                     's' => {
    38.                         continue;
    39.                     },
    40.                     else => @compileError("Unknown format character: " ++ [1]u8{c}),
    41.                 },
    42.                 State.close_brace => switch (c) {
    43.                     '}' => {
    44.                         state = State.start;
    45.                         start_index = i;
    46.                     },
    47.                     else => @compileError("Single '}' encountered in format string"),
    48.                 },
    49.             }
    50.         }
    51.         comptime {
    52.             if (args.len != next_arg) {
    53.                 @compileError("Unused arguments");
    54.             }
    55.             if (state != State.start) {
    56.                 @compileError("Incomplete format string: " ++ format);
    57.             }
    58.         }
    59.         if (start_index < format.len) {
    60.             try self.write(format[start_index..format.len]);
    61.         }
    62.         try self.flush();
    63.     }
    65.     fn write(self: *Writer, value: []const u8) !void {
    66.         _ = self;
    67.         _ = value;
    68.     }
    69.     pub fn printValue(self: *Writer, value: anytype) !void {
    70.         _ = self;
    71.         _ = value;
    72.     }
    73.     fn flush(self: *Writer) !void {
    74.         _ = self;
    75.     }
    76. };

    This is a proof of concept implementation; the actual function in the standard library has more formatting capabilities.

    Note that this is not hard-coded into the Zig compiler; this is userland code in the standard library.

    When this function is analyzed from our example code above, Zig partially evaluates the function and emits a function that actually looks like this:

    Emitted print Function

    1. pub fn print(self: *Writer, arg0: []const u8, arg1: i32) !void {
    2.     try self.write("here is a string: '");
    3.     try self.printValue(arg0);
    4.     try self.write("' here is a number: ");
    5.     try self.printValue(arg1);
    6.     try self.write("\n");
    7.     try self.flush();
    8. }

    printValue is a function that takes a parameter of any type, and does different things depending on the type:

    poc_printValue_fn.zig

    1. const Writer = struct {
    2.     pub fn printValue(self: *Writer, value: anytype) !void {
    3.         switch (@typeInfo(@TypeOf(value))) {
    4.             .Int => {
    5.                 return self.writeInt(value);
    6.             },
    7.             .Float => {
    8.                 return self.writeFloat(value);
    9.             },
    10.             .Pointer => {
    11.                 return self.write(value);
    12.             },
    13.             else => {
    14.                 @compileError("Unable to print type '" ++ @typeName(@TypeOf(value)) ++ "'");
    15.             },
    16.         }
    17.     }
    19.     fn write(self: *Writer, value: []const u8) !void {
    20.         _ = self;
    21.         _ = value;
    22.     }
    23.     fn writeInt(self: *Writer, value: anytype) !void {
    24.         _ = self;
    25.         _ = value;
    26.     }
    27.     fn writeFloat(self: *Writer, value: anytype) !void {
    28.         _ = self;
    29.         _ = value;
    30.     }
    31. };

    And now, what happens if we give too many arguments to print?

    test.zig

    1. const print = @import("std").debug.print;
    3. const a_number: i32 = 1234;
    4. const a_string = "foobar";
    6. test "print too many arguments" {
    7.     print("here is a string: '{s}' here is a number: {}\n", .{
    8.         a_string,
    9.         a_number,
    10.         a_number,
    11.     });
    12. }

    Shell

    1. $ zig test test.zig
    2. ./lib/std/fmt.zig:360:18: error: Unused argument in 'here is a string: '{s}' here is a number: {}
    3. '
    4.             1 => @compileError("Unused argument in '" ++ fmt ++ "'"),
    5.                  ^
    6. ./lib/std/io/writer.zig:28:34: note: called from here
    7.             return std.fmt.format(self, format, args);
    8.                                  ^
    9. ./lib/std/debug.zig:66:27: note: called from here
    10.     nosuspend stderr.print(fmt, args) catch return;
    11.                           ^
    12. ./docgen_tmp/test.zig:7:10: note: called from here
    13.     print("here is a string: '{s}' here is a number: {}\n", .{
    14.          ^
    15. ./docgen_tmp/test.zig:6:33: note: called from here
    16. test "print too many arguments" {
    17.                                 ^
    18. ./lib/std/io/writer.zig:28:34: error: expected type 'std.os.WriteError!void', found '@typeInfo(@typeInfo(@TypeOf(std.fmt.format)).Fn.return_type.?).ErrorUnion.error_set!void'
    19.             return std.fmt.format(self, format, args);
    20.                                  ^
    21. ./lib/std/debug.zig:66:27: note: called from here
    22.     nosuspend stderr.print(fmt, args) catch return;
    23.                           ^
    24. ./docgen_tmp/test.zig:7:10: note: called from here
    25.     print("here is a string: '{s}' here is a number: {}\n", .{
    26.          ^
    27. ./docgen_tmp/test.zig:6:33: note: called from here
    28. test "print too many arguments" {
    29.                                 ^
    30. ./lib/std/io/writer.zig:28:34: note: error set '@typeInfo(@typeInfo(@TypeOf(std.fmt.format)).Fn.return_type.?).ErrorUnion.error_set' cannot cast into error set 'std.os.WriteError'
    31.             return std.fmt.format(self, format, args);
    32.                                  ^

    Zig gives programmers the tools needed to protect themselves against their own mistakes.

    Zig doesn’t care whether the format argument is a string literal, only that it is a compile-time known value that can be coerced to a []const u8:

    print.zig

    1. const print = @import("std").debug.print;
    3. const a_number: i32 = 1234;
    4. const a_string = "foobar";
    5. const fmt = "here is a string: '{s}' here is a number: {}\n";
    7. pub fn main() void {
    9. }

    Shell

    This works fine.

    Zig does not special case string formatting in the compiler and instead exposes enough power to accomplish this task in userland. It does so without introducing another language on top of Zig, such as a macro language or a preprocessor language. It’s Zig all the way down.