Introduction §

Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

• Robust - behavior is correct even for edge cases such as out of memory.
• Optimal - write programs the best way they can behave and perform.
• Reusable - the same code works in many environments which have different constraints.
• Maintainable - precisely communicate intent to the compiler and other programmers. The language imposes a low overhead to reading code and is resilient to changing requirements and environments.

Often the most efficient way to learn something new is to see examples, so this documentation shows how to use each of Zig's features. It is all on one page so you can search with your browser's search tool.

The code samples in this document are compiled and tested as part of the main test suite of Zig.

This HTML document depends on no external files, so you can use it offline.

Where is the documentation for the Zig standard library?

Hello World §

hello.zig

const std = @import("std");

pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!\n", .{"world"});
}

$ zig build-exe hello.zig
$ ./hello
Hello, world!

The Zig code sample above demonstrates one way to create a program that will output Hello, world!.

The code sample shows the contents of a file named hello.zig. Files storing Zig source code are UTF-8 encoded text files. The files storing Zig source code are usually named with the .zig extension.

Following the hello.zig Zig code sample, the Zig Build System is used to build an executable program from the hello.zig source code. Then, the hello program is executed showing its output Hello, world!. The lines beginning with $ represent command line prompts and a command. Everything else is program output.

The code sample begins by adding Zig's Standard Library to the build using the @import builtin function. The @import("std") function call creates a structure to represent the Standard Library. The code then declares a constant identifier, named std, for easy access to Zig's standard library.

Next, a public function, pub fn, named main is declared. The main function is necessary because it tells the Zig compiler where the start of the program exists. Programs designed to be executed will need a pub fn main function. For more advanced use cases, Zig offers other features to inform the compiler where the start of the program exists. Libraries, on the other hand, do not need a main function because library code is usually called by other programs.

A function is a block of any number of statements and expressions that, as a whole, perform a task. Functions may or may not return data after they are done performing their task. If a function cannot perform its task, it might return an error. Zig makes all of this explicit.

In the hello.zig code sample, the main function is declared with the !void return type. This return type is known as an Error Union Type. This syntax tells the Zig compiler that the function will either return an error or a value. An error union type combines an Error Set Type and a Primitive Type. The full form of an error union type is <error set type>!<primitive type>. In the code sample, the error set type is not explicitly written on the left side of the ! operator. When written this way, the error set type is a special kind of error union type that has an inferred error set type. The void after the ! operator tells the compiler that the function will not return a value under normal circumstances (i.e. no errors occur).

Note to experienced programmers: Zig also has the boolean operator !a where a is a value of type bool. Error union types contain the name of the type in the syntax: !<primitive type>.

In Zig, a function's block of statements and expressions are surrounded by { and } curly-braces. Inside of the main function are expressions that perform the task of outputting Hello, world! to standard output.

First, a constant identifier, stdout, is initialized to represent standard output's writer. Then, the program tries to print the Hello, world! message to standard output.

Functions sometimes need information to perform their task. In Zig, information is passed to functions between open ( and close ) parenthesis placed after the function's name. This information is also known as arguments. When there are multiple arguments passed to a function, they are separated by commas ,.

The two arguments passed to the stdout.print() function, "Hello, {s}!\n" and .{"world"}, are evaluated at compile-time. The code sample is purposely written to show how to perform string substitution in the print function. The curly-braces inside of the first argument are substituted with the compile-time known value inside of the second argument (known as an anonymous struct literal). The \n inside of the double-quotes of the first argument is the escape sequence for the newline character. The try expression evaluates the result of stdout.print. If the result is an error, then the try expression will return from main with the error. Otherwise, the program will continue. In this case, there are no more statements or expressions left to execute in the main function, so the program exits.

In Zig, the standard output writer's print function is allowed to fail because it is actually a function defined as part of a generic Writer. Consider a generic Writer that represents writing data to a file. When the disk is full, a write to the file will fail. However, we typically do not expect writing text to the standard output to fail. To avoid having to handle the failure case of printing to standard output, you can use alternate functions: the functions in std.log for proper logging or the std.debug.print function. This documentation will use the latter option to print to standard error (stderr) and silently return on failure. The next code sample, hello_again.zig demonstrates the use of std.debug.print.

hello_again.zig

const print = @import("std").debug.print;

pub fn main() void {
    print("Hello, world!\n", .{});
}

$ zig build-exe hello_again.zig
$ ./hello_again
Hello, world!

Note that you can leave off the ! from the return type because std.debug.print cannot fail.

See also:

• Values
• @import
• Errors
• Root Source File
• Source Encoding

Comments §

comments.zig

const expect = @import("std").testing.expect;

test "comments" {
    // Comments in Zig start with "//" and end at the next LF byte (end of line).
    // The below line is a comment, and won't be executed.

    //expect(false);

    const x = true;  // another comment
    try expect(x);
}

$ zig test comments.zig
Test [1/1] test "comments"... 

All 1 tests passed.

There are no multiline comments in Zig (e.g. like /* */ comments in C). This helps allow Zig to have the property that each line of code can be tokenized out of context.

Doc comments §

A doc comment is one that begins with exactly three slashes (i.e. /// but not ////); multiple doc comments in a row are merged together to form a multiline doc comment. The doc comment documents whatever immediately follows it.

/// A structure for storing a timestamp, with nanosecond precision (this is a
/// multiline doc comment).
const Timestamp = struct {
    /// The number of seconds since the epoch (this is also a doc comment).
    seconds: i64,  // signed so we can represent pre-1970 (not a doc comment)
    /// The number of nanoseconds past the second (doc comment again).
    nanos: u32,

    /// Returns a `Timestamp` struct representing the Unix epoch; that is, the
    /// moment of 1970 Jan 1 00:00:00 UTC (this is a doc comment too).
    pub fn unixEpoch() Timestamp {
        return Timestamp{
            .seconds = 0,
            .nanos = 0,
        };
    }
};

Doc comments are only allowed in certain places; eventually, it will become a compile error to have a doc comment in an unexpected place, such as in the middle of an expression, or just before a non-doc comment.

Top-Level Doc Comments §

User documentation that doesn't belong to whatever immediately follows it, like package-level documentation, goes in top-level doc comments. A top-level doc comment is one that begins with two slashes and an exclamation point: //!.

//! This module provides functions for retrieving the current date and
//! time with varying degrees of precision and accuracy. It does not
//! depend on libc, but will use functions from it if available.

Values §

values.zig

// Top-level declarations are order-independent:
const print = std.debug.print;
const std = @import("std");
const os = std.os;
const assert = std.debug.assert;

pub fn main() void {
    // integers
    const one_plus_one: i32 = 1 + 1;
    print("1 + 1 = {}\n", .{one_plus_one});

    // floats
    const seven_div_three: f32 = 7.0 / 3.0;
    print("7.0 / 3.0 = {}\n", .{seven_div_three});

    // boolean
    print("{}\n{}\n{}\n", .{
        true and false,
        true or false,
        !true,
    });

    // optional
    var optional_value: ?[]const u8 = null;
    assert(optional_value == null);

    print("\noptional 1\ntype: {s}\nvalue: {s}\n", .{
        @typeName(@TypeOf(optional_value)),
        optional_value,
    });

    optional_value = "hi";
    assert(optional_value != null);

    print("\noptional 2\ntype: {s}\nvalue: {s}\n", .{
        @typeName(@TypeOf(optional_value)),
        optional_value,
    });

    // error union
    var number_or_error: anyerror!i32 = error.ArgNotFound;

    print("\nerror union 1\ntype: {s}\nvalue: {}\n", .{
        @typeName(@TypeOf(number_or_error)),
        number_or_error,
    });

    number_or_error = 1234;

    print("\nerror union 2\ntype: {s}\nvalue: {}\n", .{
        @typeName(@TypeOf(number_or_error)),
        number_or_error,
    });
}

$ zig build-exe values.zig
$ ./values
1 + 1 = 2
7.0 / 3.0 = 2.33333325e+00
false
true
false

optional 1
type: ?[]const u8
value: null

optional 2
type: ?[]const u8
value: hi

error union 1
type: anyerror!i32
value: error.ArgNotFound

error union 2
type: anyerror!i32
value: 1234

Primitive Types §

In addition to the integer types above, arbitrary bit-width integers can be referenced by using an identifier of i or u followed by digits. For example, the identifier i7 refers to a signed 7-bit integer. The maximum allowed bit-width of an integer type is 65535.

See also:

• Integers
• Floats
• void
• Errors
• @Type

Primitive Values §

See also:

• Optionals
• undefined

String Literals and Unicode Code Point Literals §

String literals are constant single-item Pointers to null-terminated byte arrays. The type of string literals encodes both the length, and the fact that they are null-terminated, and thus they can be coerced to both Slices and Null-Terminated Pointers. Dereferencing string literals converts them to Arrays.

The encoding of a string in Zig is de-facto assumed to be UTF-8. Because Zig source code is UTF-8 encoded, any non-ASCII bytes appearing within a string literal in source code carry their UTF-8 meaning into the content of the string in the Zig program; the bytes are not modified by the compiler. However, it is possible to embed non-UTF-8 bytes into a string literal using \xNN notation.

Unicode code point literals have type comptime_int, the same as Integer Literals. All Escape Sequences are valid in both string literals and Unicode code point literals.

In many other programming languages, a Unicode code point literal is called a "character literal". However, there is no precise technical definition of a "character" in recent versions of the Unicode specification (as of Unicode 13.0). In Zig, a Unicode code point literal corresponds to the Unicode definition of a code point.

test.zig

const expect = @import("std").testing.expect;
const mem = @import("std").mem;

test "string literals" {
    const bytes = "hello";
    try expect(@TypeOf(bytes) == *const [5:0]u8);
    try expect(bytes.len == 5);
    try expect(bytes[1] == 'e');
    try expect(bytes[5] == 0);
    try expect('e' == '\x65');
    try expect('\u{1f4a9}' == 128169);
    try expect('💯' == 128175);
    try expect(mem.eql(u8, "hello", "h\x65llo"));
    try expect("\xff"[0] == 0xff); // non-UTF-8 strings are possible with \xNN notation.
}

$ zig test test.zig
Test [1/1] test "string literals"... 

All 1 tests passed.

See also:

• Arrays
• Zig Test
• Source Encoding

Escape Sequences §

Note that the maximum valid Unicode point is 0x10ffff.

Multiline String Literals §

Multiline string literals have no escapes and can span across multiple lines. To start a multiline string literal, use the \\ token. Just like a comment, the string literal goes until the end of the line. The end of the line is not included in the string literal. However, if the next line begins with \\ then a newline is appended and the string literal continues.

const hello_world_in_c =
    \\#include <stdio.h>
    \\
    \\int main(int argc, char **argv) {
    \\    printf("hello world\n");
    \\    return 0;
    \\}
;

See also:

• @embedFile

Assignment §

Use the const keyword to assign a value to an identifier:

test.zig

const x = 1234;

fn foo() void {
    // It works at file scope as well as inside functions.
    const y = 5678;

    // Once assigned, an identifier cannot be changed.
    y += 1;
}

test "assignment" {
    foo();
}

$ zig test test.zig
./docgen_tmp/test.zig:8:7: error: cannot assign to constant
    y += 1;
      ^

const applies to all of the bytes that the identifier immediately addresses. Pointers have their own const-ness.

If you need a variable that you can modify, use the var keyword:

test.zig

const expect = @import("std").testing.expect;

test "var" {
    var y: i32 = 5678;

    y += 1;

    try expect(y == 5679);
}

$ zig test test.zig
Test [1/1] test "var"... 

All 1 tests passed.

Variables must be initialized:

test.zig

test "initialization" {
    var x: i32;

    x = 1;
}

$ zig test test.zig
./docgen_tmp/test.zig:2:5: error: variables must be initialized
    var x: i32;
    ^

undefined §

Use undefined to leave variables uninitialized:

test.zig

const expect = @import("std").testing.expect;

test "init with undefined" {
    var x: i32 = undefined;
    x = 1;
    try expect(x == 1);
}

$ zig test test.zig
Test [1/1] test "init with undefined"... 

All 1 tests passed.

undefined can be coerced to any type. Once this happens, it is no longer possible to detect that the value is undefined. undefined means the value could be anything, even something that is nonsense according to the type. Translated into English, undefined means "Not a meaningful value. Using this value would be a bug. The value will be unused, or overwritten before being used."

In Debug mode, Zig writes 0xaa bytes to undefined memory. This is to catch bugs early, and to help detect use of undefined memory in a debugger.

Variables §

A variable is a unit of Memory storage.

Variables are never allowed to shadow identifiers from an outer scope.

It is generally preferable to use const rather than var when declaring a variable. This causes less work for both humans and computers to do when reading code, and creates more optimization opportunities.

Container Level Variables §

Container level variables have static lifetime and are order-independent and lazily analyzed. The initialization value of container level variables is implicitly comptime. If a container level variable is const then its value is comptime-known, otherwise it is runtime-known.

container_level_variables.zig

var y: i32 = add(10, x);
const x: i32 = add(12, 34);

test "container level variables" {
    try expect(x == 46);
    try expect(y == 56);
}

fn add(a: i32, b: i32) i32 {
    return a + b;
}

const std = @import("std");
const expect = std.testing.expect;

$ zig test container_level_variables.zig
Test [1/1] test "container level variables"... 

All 1 tests passed.

Container level variables may be declared inside a struct, union, or enum:

namespaced_container_level_variable.zig

const std = @import("std");
const expect = std.testing.expect;

test "namespaced container level variable" {
    try expect(foo() == 1235);
    try expect(foo() == 1236);
}

const S = struct {
    var x: i32 = 1234;
};

fn foo() i32 {
    S.x += 1;
    return S.x;
}

$ zig test namespaced_container_level_variable.zig
Test [1/1] test "namespaced container level variable"... 

All 1 tests passed.

Static Local Variables §

It is also possible to have local variables with static lifetime by using containers inside functions.

static_local_variable.zig

const std = @import("std");
  const expect = std.testing.expect;
  
  test "static local variable" {
      try expect(foo() == 1235);
      try expect(foo() == 1236);
  }
  
  fn foo() i32 {
      const S = struct {
          var x: i32 = 1234;
      };
      S.x += 1;
      return S.x;
  }

$ zig test static_local_variable.zig
Test [1/1] test "static local variable"... 

All 1 tests passed.

The extern keyword or @extern builtin function can be used to link against a variable that is exported from another object. The export keyword or @export builtin function can be used to make a variable available to other objects at link time. In both cases, the type of the variable must be C ABI compatible.

See also:

• Exporting a C Library

Thread Local Variables §

A variable may be specified to be a thread-local variable using the threadlocal keyword:

tls.zig

const std = @import("std");
const assert = std.debug.assert;

threadlocal var x: i32 = 1234;

test "thread local storage" {
    const thread1 = try std.Thread.spawn(testTls, {});
    const thread2 = try std.Thread.spawn(testTls, {});
    testTls({});
    thread1.wait();
    thread2.wait();
}

fn testTls(context: void) void {
    assert(x == 1234);
    x += 1;
    assert(x == 1235);
}

$ zig test tls.zig
Test [1/1] test "thread local storage"... 

All 1 tests passed.

For Single Threaded Builds, all thread local variables are treated as regular Container Level Variables.

Thread local variables may not be const.

Local Variables §

Local variables occur inside Functions, comptime blocks, and @cImport blocks.

When a local variable is const, it means that after initialization, the variable's value will not change. If the initialization value of a const variable is comptime-known, then the variable is also comptime-known.

A local variable may be qualified with the comptime keyword. This causes the variable's value to be comptime-known, and all loads and stores of the variable to happen during semantic analysis of the program, rather than at runtime. All variables declared in a comptime expression are implicitly comptime variables.

comptime_vars.zig

const std = @import("std");
const expect = std.testing.expect;

test "comptime vars" {
    var x: i32 = 1;
    comptime var y: i32 = 1;

    x += 1;
    y += 1;

    try expect(x == 2);
    try expect(y == 2);

    if (y != 2) {
        // This compile error never triggers because y is a comptime variable,
        // and so `y != 2` is a comptime value, and this if is statically evaluated.
        @compileError("wrong y value");
    }
}

$ zig test comptime_vars.zig
Test [1/1] test "comptime vars"... 

All 1 tests passed.

Integers §

Integer Literals §

const decimal_int = 98222;
const hex_int = 0xff;
const another_hex_int = 0xFF;
const octal_int = 0o755;
const binary_int = 0b11110000;

// underscores may be placed between two digits as a visual separator
const one_billion = 1_000_000_000;
const binary_mask = 0b1_1111_1111;
const permissions = 0o7_5_5;
const big_address = 0xFF80_0000_0000_0000;

Runtime Integer Values §

Integer literals have no size limitation, and if any undefined behavior occurs, the compiler catches it.

However, once an integer value is no longer known at compile-time, it must have a known size, and is vulnerable to undefined behavior.

fn divide(a: i32, b: i32) i32 {
    return a / b;
}

In this function, values a and b are known only at runtime, and thus this division operation is vulnerable to both Integer Overflow and Division by Zero.

Operators such as + and - cause undefined behavior on integer overflow. Also available are operations such as +% and -% which are defined to have wrapping arithmetic on all targets.

Zig supports arbitrary bit-width integers, referenced by using an identifier of i or u followed by digits. For example, the identifier i7 refers to a signed 7-bit integer. The maximum allowed bit-width of an integer type is 65535.

See also:

• Wrapping Operations

Floats §

Zig has the following floating point types:

• f16 - IEEE-754-2008 binary16
• f32 - IEEE-754-2008 binary32
• f64 - IEEE-754-2008 binary64
• f128 - IEEE-754-2008 binary128
• c_longdouble - matches long double for the target C ABI

Float Literals §

Float literals have type comptime_float which is guaranteed to have the same precision and operations of the largest other floating point type, which is f128.

Float literals coerce to any floating point type, and to any integer type when there is no fractional component.

const floating_point = 123.0E+77;
const another_float = 123.0;
const yet_another = 123.0e+77;

const hex_floating_point = 0x103.70p-5;
const another_hex_float = 0x103.70;
const yet_another_hex_float = 0x103.70P-5;

// underscores may be placed between two digits as a visual separator
const lightspeed = 299_792_458.000_000;
const nanosecond = 0.000_000_001;
const more_hex = 0x1234_5678.9ABC_CDEFp-10;

There is no syntax for NaN, infinity, or negative infinity. For these special values, one must use the standard library:

const std = @import("std");

const inf = std.math.inf(f32);
const negative_inf = -std.math.inf(f64);
const nan = std.math.nan(f128);

Floating Point Operations §

By default floating point operations use Strict mode, but you can switch to Optimized mode on a per-block basis:

foo.zig

const std = @import("std");
const big = @as(f64, 1 << 40);

export fn foo_strict(x: f64) f64 {
    return x + big - big;
}

export fn foo_optimized(x: f64) f64 {
    @setFloatMode(.Optimized);
    return x + big - big;
}

$ zig build-obj foo.zig -O ReleaseFast

For this test we have to separate code into two object files - otherwise the optimizer figures out all the values at compile-time, which operates in strict mode.

float_mode.zig

const print = @import("std").debug.print;

extern fn foo_strict(x: f64) f64;
extern fn foo_optimized(x: f64) f64;

pub fn main() void {
    const x = 0.001;
    print("optimized = {}\n", .{foo_optimized(x)});
    print("strict = {}\n", .{foo_strict(x)});
}

$ zig build-exe float_mode.zig foo.o
$ ./float_mode
optimized = 1.0e-03
strict = 9.765625e-04

See also:

• @setFloatMode
• Division by Zero

Operators §

There is no operator overloading. When you see an operator in Zig, you know that it is doing something from this table, and nothing else.

Table of Operators §

a + b
a += b

2 + 5 == 7

a +% b
a +%= b

@as(u32, std.math.maxInt(u32)) +% 1 == 0

a - b
a -= b

2 - 5 == -3

a -% b
a -%= b

@as(u32, 0) -% 1 == std.math.maxInt(u32)

-a

-1 == 0 - 1

-%a

-%@as(i32, std.math.minInt(i32)) == std.math.minInt(i32)

a * b
a *= b

2 * 5 == 10

a *% b
a *%= b

@as(u8, 200) *% 2 == 144

a / b
a /= b

10 / 5 == 2

a % b
a %= b

10 % 3 == 1

a << b
a <<= b

1 << 8 == 256

a >> b
a >>= b

10 >> 1 == 5

a & b
a &= b

0b011 & 0b101 == 0b001

a | b
a |= b

0b010 | 0b100 == 0b110

a ^ b
a ^= b

0b011 ^ 0b101 == 0b110

~a

~@as(u8, 0b10101111) == 0b01010000

a orelse b

const value: ?u32 = null;
const unwrapped = value orelse 1234;
unwrapped == 1234

a.?

a orelse unreachable

const value: ?u32 = 5678;
value.? == 5678

a catch b
a catch |err| b

const value: anyerror!u32 = error.Broken;
const unwrapped = value catch 1234;
unwrapped == 1234

a and b

(false and true) == false

a or b

false or true == true

!a

!false == true

a == b

(1 == 1) == true

a == null

const value: ?u32 = null;
value == null

a != b

(1 != 1) == false

a > b

(2 > 1) == true

a >= b

(2 >= 1) == true

a < b

(1 < 2) == true>

a <= b

(1 <= 2) == true

a ++ b

const mem = @import("std").mem;
const array1 = [_]u32{1,2};
const array2 = [_]u32{3,4};
const together = array1 ++ array2;
mem.eql(u32, &together, &[_]u32{1,2,3,4})

a ** b

const mem = @import("std").mem;
const pattern = "ab" ** 3;
mem.eql(u8, pattern, "ababab")

a.*

const x: u32 = 1234;
const ptr = &x;
ptr.* == 1234

&a

const x: u32 = 1234;
const ptr = &x;
ptr.* == 1234

a || b

const A = error{One};
const B = error{Two};
(A || B) == error{One, Two}

Precedence §

x() x[] x.y x.* x.?
a!b
x{}
!x -x -%x ~x &x ?x
* / % ** *% ||
+ - ++ +% -%
<< >>
& ^ | orelse catch
== != < > <= >=
and
or
= *= /= %= += -= <<= >>= &= ^= |=

Arrays §

arrays.zig

const expect = @import("std").testing.expect;
const assert = @import("std").debug.assert;
const mem = @import("std").mem;

// array literal
const message = [_]u8{ 'h', 'e', 'l', 'l', 'o' };

// get the size of an array
comptime {
    assert(message.len == 5);
}

// A string literal is a single-item pointer to an array literal.
const same_message = "hello";

comptime {
    assert(mem.eql(u8, &message, same_message));
}

test "iterate over an array" {
    var sum: usize = 0;
    for (message) |byte| {
        sum += byte;
    }
    try expect(sum == 'h' + 'e' + 'l' * 2 + 'o');
}

// modifiable array
var some_integers: [100]i32 = undefined;

test "modify an array" {
    for (some_integers) |*item, i| {
        item.* = @intCast(i32, i);
    }
    try expect(some_integers[10] == 10);
    try expect(some_integers[99] == 99);
}

// array concatenation works if the values are known
// at compile time
const part_one = [_]i32{ 1, 2, 3, 4 };
const part_two = [_]i32{ 5, 6, 7, 8 };
const all_of_it = part_one ++ part_two;
comptime {
    assert(mem.eql(i32, &all_of_it, &[_]i32{ 1, 2, 3, 4, 5, 6, 7, 8 }));
}

// remember that string literals are arrays
const hello = "hello";
const world = "world";
const hello_world = hello ++ " " ++ world;
comptime {
    assert(mem.eql(u8, hello_world, "hello world"));
}

// ** does repeating patterns
const pattern = "ab" ** 3;
comptime {
    assert(mem.eql(u8, pattern, "ababab"));
}

// initialize an array to zero
const all_zero = [_]u16{0} ** 10;

comptime {
    assert(all_zero.len == 10);
    assert(all_zero[5] == 0);
}

// use compile-time code to initialize an array
var fancy_array = init: {
    var initial_value: [10]Point = undefined;
    for (initial_value) |*pt, i| {
        pt.* = Point{
            .x = @intCast(i32, i),
            .y = @intCast(i32, i) * 2,
        };
    }
    break :init initial_value;
};
const Point = struct {
    x: i32,
    y: i32,
};

test "compile-time array initialization" {
    try expect(fancy_array[4].x == 4);
    try expect(fancy_array[4].y == 8);
}

// call a function to initialize an array
var more_points = [_]Point{makePoint(3)} ** 10;
fn makePoint(x: i32) Point {
    return Point{
        .x = x,
        .y = x * 2,
    };
}
test "array initialization with function calls" {
    try expect(more_points[4].x == 3);
    try expect(more_points[4].y == 6);
    try expect(more_points.len == 10);
}

$ zig test arrays.zig
Test [1/4] test "iterate over an array"... 
Test [2/4] test "modify an array"... 
Test [3/4] test "compile-time array initialization"... 
Test [4/4] test "array initialization with function calls"... 

All 4 tests passed.

See also:

• for
• Slices

Anonymous List Literals §

Similar to Enum Literals and Anonymous Struct Literals the type can be omitted from array literals:

anon_list.zig

const std = @import("std");
const expect = std.testing.expect;

test "anonymous list literal syntax" {
    var array: [4]u8 = .{11, 22, 33, 44};
    try expect(array[0] == 11);
    try expect(array[1] == 22);
    try expect(array[2] == 33);
    try expect(array[3] == 44);
}

$ zig test anon_list.zig
Test [1/1] test "anonymous list literal syntax"... 

All 1 tests passed.

If there is no type in the result location then an anonymous list literal actually turns into a struct with numbered field names:

infer_list_literal.zig

const std = @import("std");
const expect = std.testing.expect;

test "fully anonymous list literal" {
    try dump(.{ @as(u32, 1234), @as(f64, 12.34), true, "hi"});
}

fn dump(args: anytype) !void {
    try expect(args.@"0" == 1234);
    try expect(args.@"1" == 12.34);
    try expect(args.@"2");
    try expect(args.@"3"[0] == 'h');
    try expect(args.@"3"[1] == 'i');
}

$ zig test infer_list_literal.zig
Test [1/1] test "fully anonymous list literal"... 

All 1 tests passed.

Multidimensional Arrays §

Mutlidimensional arrays can be created by nesting arrays:

multidimensional.zig

const std = @import("std");
const expect = std.testing.expect;

const mat4x4 = [4][4]f32{
    [_]f32{ 1.0, 0.0, 0.0, 0.0 },
    [_]f32{ 0.0, 1.0, 0.0, 1.0 },
    [_]f32{ 0.0, 0.0, 1.0, 0.0 },
    [_]f32{ 0.0, 0.0, 0.0, 1.0 },
};
test "multidimensional arrays" {
    // Access the 2D array by indexing the outer array, and then the inner array.
    try expect(mat4x4[1][1] == 1.0);

    // Here we iterate with for loops.
    for (mat4x4) |row, row_index| {
        for (row) |cell, column_index| {
            if (row_index == column_index) {
                try expect(cell == 1.0);
            }
        }
    }
}

$ zig test multidimensional.zig
Test [1/1] test "multidimensional arrays"... 

All 1 tests passed.

Sentinel-Terminated Arrays §

The syntax [N:x]T describes an array which has a sentinel element of value x at the index corresponding to len.

null_terminated_array.zig

const std = @import("std");
const expect = std.testing.expect;

test "null terminated array" {
    const array = [_:0]u8 {1, 2, 3, 4};

    try expect(@TypeOf(array) == [4:0]u8);
    try expect(array.len == 4);
    try expect(array[4] == 0);
}

$ zig test null_terminated_array.zig
Test [1/1] test "null terminated array"... 

All 1 tests passed.

See also:

• Sentinel-Terminated Pointers
• Sentinel-Terminated Slices

Vectors §

A vector is a group of booleans, Integers, Floats, or Pointers which are operated on in parallel using a single instruction (SIMD). Vector types are created with the builtin function @Type, or using the shorthand as std.meta.Vector.

TODO talk about C ABI interop

SIMD §

TODO Zig's SIMD abilities are just beginning to be fleshed out. Here are some talking points to update the docs with: * What kind of operations can you do? All the operations on integers and floats? What about mixing scalar and vector? * How to convert to/from vectors/arrays * How to access individual elements from vectors, how to loop over the elements * "shuffle" * Advice on writing high perf software, how to abstract the best way

Pointers §

Zig has two kinds of pointers: single-item and many-item.

• *T - single-item pointer to exactly one item.
  • Supports deref syntax: ptr.*
• [*]T - many-item pointer to unknown number of items.
  • Supports index syntax: ptr[i]
  • Supports slice syntax: ptr[start..end]
  • Supports pointer arithmetic: ptr + x, ptr - x
  • T must have a known size, which means that it cannot be c_void or any other opaque type.

These types are closely related to Arrays and Slices:

• *[N]T - pointer to N items, same as single-item pointer to an array.
  • Supports index syntax: array_ptr[i]
  • Supports slice syntax: array_ptr[start..end]
  • Supports len property: array_ptr.len

• []T - pointer to runtime-known number of items.
  • Supports index syntax: slice[i]
  • Supports slice syntax: slice[start..end]
  • Supports len property: slice.len

Use &x to obtain a single-item pointer:

test.zig

const expect = @import("std").testing.expect;

test "address of syntax" {
    // Get the address of a variable:
    const x: i32 = 1234;
    const x_ptr = &x;

    // Dereference a pointer:
    try expect(x_ptr.* == 1234);

    // When you get the address of a const variable, you get a const single-item pointer.
    try expect(@TypeOf(x_ptr) == *const i32);

    // If you want to mutate the value, you'd need an address of a mutable variable:
    var y: i32 = 5678;
    const y_ptr = &y;
    try expect(@TypeOf(y_ptr) == *i32);
    y_ptr.* += 1;
    try expect(y_ptr.* == 5679);
}

test "pointer array access" {
    // Taking an address of an individual element gives a
    // single-item pointer. This kind of pointer
    // does not support pointer arithmetic.
    var array = [_]u8{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    const ptr = &array[2];
    try expect(@TypeOf(ptr) == *u8);

    try expect(array[2] == 3);
    ptr.* += 1;
    try expect(array[2] == 4);
}

$ zig test test.zig
Test [1/2] test "address of syntax"... 
Test [2/2] test "pointer array access"... 

All 2 tests passed.

In Zig, we generally prefer Slices rather than Sentinel-Terminated Pointers. You can turn an array or pointer into a slice using slice syntax.

Slices have bounds checking and are therefore protected against this kind of undefined behavior. This is one reason we prefer slices to pointers.

test.zig

const expect = @import("std").testing.expect;

test "pointer slicing" {
    var array = [_]u8{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    const slice = array[2..4];
    try expect(slice.len == 2);

    try expect(array[3] == 4);
    slice[1] += 1;
    try expect(array[3] == 5);
}

$ zig test test.zig
Test [1/1] test "pointer slicing"... 

All 1 tests passed.

Pointers work at compile-time too, as long as the code does not depend on an undefined memory layout:

test.zig

const expect = @import("std").testing.expect;

test "comptime pointers" {
    comptime {
        var x: i32 = 1;
        const ptr = &x;
        ptr.* += 1;
        x += 1;
        try expect(ptr.* == 3);
    }
}

$ zig test test.zig
Test [1/1] test "comptime pointers"... 

All 1 tests passed.

To convert an integer address into a pointer, use @intToPtr. To convert a pointer to an integer, use @ptrToInt:

test.zig

const expect = @import("std").testing.expect;

test "@ptrToInt and @intToPtr" {
    const ptr = @intToPtr(*i32, 0xdeadbee0);
    const addr = @ptrToInt(ptr);
    try expect(@TypeOf(addr) == usize);
    try expect(addr == 0xdeadbee0);
}

$ zig test test.zig
Test [1/1] test "@ptrToInt and @intToPtr"... 

All 1 tests passed.

Zig is able to preserve memory addresses in comptime code, as long as the pointer is never dereferenced:

test.zig

const expect = @import("std").testing.expect;

test "comptime @intToPtr" {
    comptime {
        // Zig is able to do this at compile-time, as long as
        // ptr is never dereferenced.
        const ptr = @intToPtr(*i32, 0xdeadbee0);
        const addr = @ptrToInt(ptr);
        try expect(@TypeOf(addr) == usize);
        try expect(addr == 0xdeadbee0);
    }
}

$ zig test test.zig
Test [1/1] test "comptime @intToPtr"... 

All 1 tests passed.

See also:

• Optional Pointers
• @intToPtr
• @ptrToInt
• C Pointers
• Pointers to Zero Bit Types

volatile §

Loads and stores are assumed to not have side effects. If a given load or store should have side effects, such as Memory Mapped Input/Output (MMIO), use volatile. In the following code, loads and stores with mmio_ptr are guaranteed to all happen and in the same order as in source code:

test.zig

const expect = @import("std").testing.expect;

test "volatile" {
    const mmio_ptr = @intToPtr(*volatile u8, 0x12345678);
    try expect(@TypeOf(mmio_ptr) == *volatile u8);
}

$ zig test test.zig
Test [1/1] test "volatile"... 

All 1 tests passed.

Note that volatile is unrelated to concurrency and Atomics. If you see code that is using volatile for something other than Memory Mapped Input/Output, it is probably a bug.

To convert one pointer type to another, use @ptrCast. This is an unsafe operation that Zig cannot protect you against. Use @ptrCast only when other conversions are not possible.

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "pointer casting" {
    const bytes align(@alignOf(u32)) = [_]u8{ 0x12, 0x12, 0x12, 0x12 };
    const u32_ptr = @ptrCast(*const u32, &bytes);
    try expect(u32_ptr.* == 0x12121212);

    // Even this example is contrived - there are better ways to do the above than
    // pointer casting. For example, using a slice narrowing cast:
    const u32_value = std.mem.bytesAsSlice(u32, bytes[0..])[0];
    try expect(u32_value == 0x12121212);

    // And even another way, the most straightforward way to do it:
    try expect(@bitCast(u32, bytes) == 0x12121212);
}

test "pointer child type" {
    // pointer types have a `child` field which tells you the type they point to.
    try expect(@typeInfo(*u32).Pointer.child == u32);
}

$ zig test test.zig
Test [1/2] test "pointer casting"... 
Test [2/2] test "pointer child type"... 

All 2 tests passed.

Alignment §

Each type has an alignment - a number of bytes such that, when a value of the type is loaded from or stored to memory, the memory address must be evenly divisible by this number. You can use @alignOf to find out this value for any type.

Alignment depends on the CPU architecture, but is always a power of two, and less than 1 << 29.

In Zig, a pointer type has an alignment value. If the value is equal to the alignment of the underlying type, it can be omitted from the type:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "variable alignment" {
    var x: i32 = 1234;
    const align_of_i32 = @alignOf(@TypeOf(x));
    try expect(@TypeOf(&x) == *i32);
    try expect(*i32 == *align(align_of_i32) i32);
    if (std.Target.current.cpu.arch == .x86_64) {
        try expect(@typeInfo(*i32).Pointer.alignment == 4);
    }
}

$ zig test test.zig
Test [1/1] test "variable alignment"... 

All 1 tests passed.

In the same way that a *i32 can be coerced to a *const i32, a pointer with a larger alignment can be implicitly cast to a pointer with a smaller alignment, but not vice versa.

You can specify alignment on variables and functions. If you do this, then pointers to them get the specified alignment:

test.zig

const expect = @import("std").testing.expect;

var foo: u8 align(4) = 100;

test "global variable alignment" {
    try expect(@typeInfo(@TypeOf(&foo)).Pointer.alignment == 4);
    try expect(@TypeOf(&foo) == *align(4) u8);
    const as_pointer_to_array: *[1]u8 = &foo;
    const as_slice: []u8 = as_pointer_to_array;
    try expect(@TypeOf(as_slice) == []align(4) u8);
}

fn derp() align(@sizeOf(usize) * 2) i32 { return 1234; }
fn noop1() align(1) void {}
fn noop4() align(4) void {}

test "function alignment" {
    try expect(derp() == 1234);
    try expect(@TypeOf(noop1) == fn() align(1) void);
    try expect(@TypeOf(noop4) == fn() align(4) void);
    noop1();
    noop4();
}

$ zig test test.zig
Test [1/2] test "global variable alignment"... 
Test [2/2] test "function alignment"... 

All 2 tests passed.

If you have a pointer or a slice that has a small alignment, but you know that it actually has a bigger alignment, use @alignCast to change the pointer into a more aligned pointer. This is a no-op at runtime, but inserts a safety check:

test.zig

const std = @import("std");

test "pointer alignment safety" {
    var array align(4) = [_]u32{ 0x11111111, 0x11111111 };
    const bytes = std.mem.sliceAsBytes(array[0..]);
    try std.testing.expect(foo(bytes) == 0x11111111);
}
fn foo(bytes: []u8) u32 {
    const slice4 = bytes[1..5];
    const int_slice = std.mem.bytesAsSlice(u32, @alignCast(4, slice4));
    return int_slice[0];
}

$ zig test test.zig 
Test [1/1] test "pointer alignment safety"... 
thread 10521 panic: incorrect alignment
/home/andy/Downloads/zig/docgen_tmp/test.zig:10:63: 0x2081bc in foo (test)
    const int_slice = std.mem.bytesAsSlice(u32, @alignCast(4, slice4));
                                                              ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:6:31: 0x206799 in test "pointer alignment safety" (test)
    try std.testing.expect(foo(bytes) == 0x11111111);
                              ^
/home/andy/Downloads/zig/lib/std/special/test_runner.zig:76:28: 0x22d2da in std.special.main (test)
        } else test_fn.func();
                           ^
/home/andy/Downloads/zig/lib/std/start.zig:471:37: 0x22583a in std.start.callMain (test)
            const result = root.main() catch |err| {
                                    ^
/home/andy/Downloads/zig/lib/std/start.zig:413:12: 0x20970e in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:332:17: 0x2086a6 in std.start.posixCallMainAndExit (test)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/andy/Downloads/zig/lib/std/start.zig:245:5: 0x2084b2 in std.start._start (test)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
error: the following test command crashed:
docgen_tmp/zig-cache/o/333a8741816702dafd0ff99af380ebb1/test /home/andy/Downloads/zig/build-release/zig

allowzero §

This pointer attribute allows a pointer to have address zero. This is only ever needed on the freestanding OS target, where the address zero is mappable. If you want to represent null pointers, use Optional Pointers instead. Optional Pointers with allowzero are not the same size as pointers. In this code example, if the pointer did not have the allowzero attribute, this would be a Pointer Cast Invalid Null panic:

allowzero.zig

const std = @import("std");
const expect = std.testing.expect;

test "allowzero" {
    var zero: usize = 0;
    var ptr = @intToPtr(*allowzero i32, zero);
    try expect(@ptrToInt(ptr) == 0);
}

$ zig test allowzero.zig
Test [1/1] test "allowzero"... 

All 1 tests passed.

Sentinel-Terminated Pointers §

The syntax [*:x]T describes a pointer that has a length determined by a sentinel value. This provides protection against buffer overflow and overreads.

test.zig

const std = @import("std");

// This is also available as `std.c.printf`.
pub extern "c" fn printf(format: [*:0]const u8, ...) c_int;

pub fn main() anyerror!void {
    _ = printf("Hello, world!\n"); // OK

    const msg = "Hello, world!\n";
    const non_null_terminated_msg: [msg.len]u8 = msg.*;
    _ = printf(&non_null_terminated_msg);
}

$ zig build-exe test.zig -lc
./docgen_tmp/test.zig:11:17: error: expected type '[*:0]const u8', found '*const [14]u8'
    _ = printf(&non_null_terminated_msg);
                ^
./docgen_tmp/test.zig:11:17: note: destination pointer requires a terminating '0' sentinel
    _ = printf(&non_null_terminated_msg);
                ^

See also:

• Sentinel-Terminated Slices
• Sentinel-Terminated Arrays

Slices §

test.zig

const expect = @import("std").testing.expect;

test "basic slices" {
    var array = [_]i32{ 1, 2, 3, 4 };
    // A slice is a pointer and a length. The difference between an array and
    // a slice is that the array's length is part of the type and known at
    // compile-time, whereas the slice's length is known at runtime.
    // Both can be accessed with the `len` field.
    var known_at_runtime_zero: usize = 0;
    const slice = array[known_at_runtime_zero..array.len];
    try expect(&slice[0] == &array[0]);
    try expect(slice.len == array.len);

    // Using the address-of operator on a slice gives a single-item pointer,
    // while using the `ptr` field gives a many-item pointer.
    try expect(@TypeOf(slice.ptr) == [*]i32);
    try expect(@TypeOf(&slice[0]) == *i32);
    try expect(@ptrToInt(slice.ptr) == @ptrToInt(&slice[0]));

    // Slices have array bounds checking. If you try to access something out
    // of bounds, you'll get a safety check failure:
    slice[10] += 1;

    // Note that `slice.ptr` does not invoke safety checking, while `&slice[0]`
    // asserts that the slice has len >= 1.
}

$ zig test test.zig 
Test [1/1] test "basic slices"... 
thread 10827 panic: index out of bounds
/home/andy/Downloads/zig/docgen_tmp/test.zig:22:10: 0x2069b3 in test "basic slices" (test)
    slice[10] += 1;
         ^
/home/andy/Downloads/zig/lib/std/special/test_runner.zig:76:28: 0x22d2da in std.special.main (test)
        } else test_fn.func();
                           ^
/home/andy/Downloads/zig/lib/std/start.zig:471:37: 0x22583a in std.start.callMain (test)
            const result = root.main() catch |err| {
                                    ^
/home/andy/Downloads/zig/lib/std/start.zig:413:12: 0x20970e in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:332:17: 0x208736 in std.start.posixCallMainAndExit (test)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/andy/Downloads/zig/lib/std/start.zig:245:5: 0x208542 in std.start._start (test)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
error: the following test command crashed:
docgen_tmp/zig-cache/o/333a8741816702dafd0ff99af380ebb1/test /home/andy/Downloads/zig/build-release/zig

This is one reason we prefer slices to pointers.

slices.zig

const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;
const fmt = std.fmt;

test "using slices for strings" {
    // Zig has no concept of strings. String literals are const pointers
    // to null-terminated arrays of u8, and by convention parameters
    // that are "strings" are expected to be UTF-8 encoded slices of u8.
    // Here we coerce *const [5:0]u8 and *const [6:0]u8 to []const u8
    const hello: []const u8 = "hello";
    const world: []const u8 = "世界";

    var all_together: [100]u8 = undefined;
    // You can use slice syntax on an array to convert an array into a slice.
    const all_together_slice = all_together[0..];
    // String concatenation example.
    const hello_world = try fmt.bufPrint(all_together_slice, "{s} {s}", .{ hello, world });

    // Generally, you can use UTF-8 and not worry about whether something is a
    // string. If you don't need to deal with individual characters, no need
    // to decode.
    try expect(mem.eql(u8, hello_world, "hello 世界"));
}

test "slice pointer" {
    var array: [10]u8 = undefined;
    const ptr = &array;

    // You can use slicing syntax to convert a pointer into a slice:
    const slice = ptr[0..5];
    slice[2] = 3;
    try expect(slice[2] == 3);
    // The slice is mutable because we sliced a mutable pointer.
    // Furthermore, it is actually a pointer to an array, since the start
    // and end indexes were both comptime-known.
    try expect(@TypeOf(slice) == *[5]u8);

    // You can also slice a slice:
    const slice2 = slice[2..3];
    try expect(slice2.len == 1);
    try expect(slice2[0] == 3);
}

$ zig test slices.zig
Test [1/2] test "using slices for strings"... 
Test [2/2] test "slice pointer"... 

All 2 tests passed.

See also:

• Pointers
• for
• Arrays

Sentinel-Terminated Slices §

The syntax [:x]T is a slice which has a runtime known length and also guarantees a sentinel value at the element indexed by the length. The type does not guarantee that there are no sentinel elements before that. Sentinel-terminated slices allow element access to the len index.

null_terminated_slice.zig

const std = @import("std");
const expect = std.testing.expect;

test "null terminated slice" {
    const slice: [:0]const u8 = "hello";

    try expect(slice.len == 5);
    try expect(slice[5] == 0);
}

$ zig test null_terminated_slice.zig
Test [1/1] test "null terminated slice"... 

All 1 tests passed.

See also:

• Sentinel-Terminated Pointers
• Sentinel-Terminated Arrays

struct §

structs.zig

// Declare a struct.
// Zig gives no guarantees about the order of fields and the size of
// the struct but the fields are guaranteed to be ABI-aligned.
const Point = struct {
    x: f32,
    y: f32,
};

// Maybe we want to pass it to OpenGL so we want to be particular about
// how the bytes are arranged.
const Point2 = packed struct {
    x: f32,
    y: f32,
};


// Declare an instance of a struct.
const p = Point {
    .x = 0.12,
    .y = 0.34,
};

// Maybe we're not ready to fill out some of the fields.
var p2 = Point {
    .x = 0.12,
    .y = undefined,
};

// Structs can have methods
// Struct methods are not special, they are only namespaced
// functions that you can call with dot syntax.
const Vec3 = struct {
    x: f32,
    y: f32,
    z: f32,

    pub fn init(x: f32, y: f32, z: f32) Vec3 {
        return Vec3 {
            .x = x,
            .y = y,
            .z = z,
        };
    }

    pub fn dot(self: Vec3, other: Vec3) f32 {
        return self.x * other.x + self.y * other.y + self.z * other.z;
    }
};

const expect = @import("std").testing.expect;
test "dot product" {
    const v1 = Vec3.init(1.0, 0.0, 0.0);
    const v2 = Vec3.init(0.0, 1.0, 0.0);
    try expect(v1.dot(v2) == 0.0);

    // Other than being available to call with dot syntax, struct methods are
    // not special. You can reference them as any other declaration inside
    // the struct:
    try expect(Vec3.dot(v1, v2) == 0.0);
}

// Structs can have declarations.
// Structs can have 0 fields.
const Empty = struct {
    pub const PI = 3.14;
};
test "struct namespaced variable" {
    try expect(Empty.PI == 3.14);
    try expect(@sizeOf(Empty) == 0);

    // you can still instantiate an empty struct
    const does_nothing = Empty {};
}

// struct field order is determined by the compiler for optimal performance.
// however, you can still calculate a struct base pointer given a field pointer:
fn setYBasedOnX(x: *f32, y: f32) void {
    const point = @fieldParentPtr(Point, "x", x);
    point.y = y;
}
test "field parent pointer" {
    var point = Point {
        .x = 0.1234,
        .y = 0.5678,
    };
    setYBasedOnX(&point.x, 0.9);
    try expect(point.y == 0.9);
}

// You can return a struct from a function. This is how we do generics
// in Zig:
fn LinkedList(comptime T: type) type {
    return struct {
        pub const Node = struct {
            prev: ?*Node,
            next: ?*Node,
            data: T,
        };

        first: ?*Node,
        last:  ?*Node,
        len:   usize,
    };
}

test "linked list" {
    // Functions called at compile-time are memoized. This means you can
    // do this:
    try expect(LinkedList(i32) == LinkedList(i32));

    var list = LinkedList(i32) {
        .first = null,
        .last = null,
        .len = 0,
    };
    try expect(list.len == 0);

    // Since types are first class values you can instantiate the type
    // by assigning it to a variable:
    const ListOfInts = LinkedList(i32);
    try expect(ListOfInts == LinkedList(i32));

    var node = ListOfInts.Node {
        .prev = null,
        .next = null,
        .data = 1234,
    };
    var list2 = LinkedList(i32) {
        .first = &node,
        .last = &node,
        .len = 1,
    };
    try expect(list2.first.?.data == 1234);
}

$ zig test structs.zig
Test [1/4] test "dot product"... 
Test [2/4] test "struct namespaced variable"... 
Test [3/4] test "field parent pointer"... 
Test [4/4] test "linked list"... 

All 4 tests passed.

Default Field Values §

Each struct field may have an expression indicating the default field value. Such expressions are executed at comptime, and allow the field to be omitted in a struct literal expression:

test.zig

const Foo = struct {
    a: i32 = 1234,
    b: i32,
};

test "default struct initialization fields" {
    const x = Foo{
        .b = 5,
    };
    if (x.a + x.b != 1239) {
        @compileError("it's even comptime known!");
    }
}

$ zig test test.zig
Test [1/1] test "default struct initialization fields"... 

All 1 tests passed.

extern struct §

An extern struct has in-memory layout guaranteed to match the C ABI for the target.

This kind of struct should only be used for compatibility with the C ABI. Every other use case should be solved with packed struct or normal struct.

See also:

• extern union
• extern enum

packed struct §

Unlike normal structs, packed structs have guaranteed in-memory layout:

• Fields remain in the order declared.
• There is no padding between fields.
• Zig supports arbitrary width Integers and although normally, integers with fewer than 8 bits will still use 1 byte of memory, in packed structs, they use exactly their bit width.
• bool fields use exactly 1 bit.
• An enum field uses exactly the bit width of its integer tag type.
• A packed union field uses exactly the bit width of the union field with the largest bit width.
• Non-ABI-aligned fields are packed into the smallest possible ABI-aligned integers in accordance with the target endianness.

This means that a packed struct can participate in a @bitCast or a @ptrCast to reinterpret memory. This even works at comptime:

test.zig

const std = @import("std");
const native_endian = @import("builtin").target.cpu.arch.endian();
const expect = std.testing.expect;

const Full = packed struct {
    number: u16,
};
const Divided = packed struct {
    half1: u8,
    quarter3: u4,
    quarter4: u4,
};

test "@bitCast between packed structs" {
    try doTheTest();
    comptime try doTheTest();
}

fn doTheTest() !void {
    try expect(@sizeOf(Full) == 2);
    try expect(@sizeOf(Divided) == 2);
    var full = Full{ .number = 0x1234 };
    var divided = @bitCast(Divided, full);
    switch (native_endian) {
        .Big => {
            try expect(divided.half1 == 0x12);
            try expect(divided.quarter3 == 0x3);
            try expect(divided.quarter4 == 0x4);
        },
        .Little => {
            try expect(divided.half1 == 0x34);
            try expect(divided.quarter3 == 0x2);
            try expect(divided.quarter4 == 0x1);
        },
    }
}

$ zig test test.zig
Test [1/1] test "@bitCast between packed structs"... 

All 1 tests passed.

Zig allows the address to be taken of a non-byte-aligned field:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const BitField = packed struct {
    a: u3,
    b: u3,
    c: u2,
};

var foo = BitField{
    .a = 1,
    .b = 2,
    .c = 3,
};

test "pointer to non-byte-aligned field" {
    const ptr = &foo.b;
    try expect(ptr.* == 2);
}

$ zig test test.zig
Test [1/1] test "pointer to non-byte-aligned field"... 

All 1 tests passed.

However, the pointer to a non-byte-aligned field has special properties and cannot be passed when a normal pointer is expected:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const BitField = packed struct {
    a: u3,
    b: u3,
    c: u2,
};

var bit_field = BitField{
    .a = 1,
    .b = 2,
    .c = 3,
};

test "pointer to non-bit-aligned field" {
    try expect(bar(&bit_field.b) == 2);
}

fn bar(x: *const u3) u3 {
    return x.*;
}

$ zig test test.zig
./docgen_tmp/test.zig:17:30: error: expected type '*const u3', found '*align(:3:1) u3'
    try expect(bar(&bit_field.b) == 2);
                             ^

In this case, the function bar cannot be called becuse the pointer to the non-ABI-aligned field mentions the bit offset, but the function expects an ABI-aligned pointer.

Pointers to non-ABI-aligned fields share the same address as the other fields within their host integer:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const BitField = packed struct {
    a: u3,
    b: u3,
    c: u2,
};

var bit_field = BitField{
    .a = 1,
    .b = 2,
    .c = 3,
};

test "pointer to non-bit-aligned field" {
    try expect(@ptrToInt(&bit_field.a) == @ptrToInt(&bit_field.b));
    try expect(@ptrToInt(&bit_field.a) == @ptrToInt(&bit_field.c));
}

$ zig test test.zig
Test [1/1] test "pointer to non-bit-aligned field"... 

All 1 tests passed.

This can be observed with @bitOffsetOf and byteOffsetOf:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const BitField = packed struct {
    a: u3,
    b: u3,
    c: u2,
};

test "pointer to non-bit-aligned field" {
    comptime {
        try expect(@bitOffsetOf(BitField, "a") == 0);
        try expect(@bitOffsetOf(BitField, "b") == 3);
        try expect(@bitOffsetOf(BitField, "c") == 6);

        try expect(@byteOffsetOf(BitField, "a") == 0);
        try expect(@byteOffsetOf(BitField, "b") == 0);
        try expect(@byteOffsetOf(BitField, "c") == 0);
    }
}

$ zig test test.zig
Test [1/1] test "pointer to non-bit-aligned field"... 

All 1 tests passed.

Packed structs have 1-byte alignment. However if you have an overaligned pointer to a packed struct, Zig should correctly understand the alignment of fields. However there is a bug:

test.zig

const S = packed struct {
    a: u32,
    b: u32,
};
test "overaligned pointer to packed struct" {
    var foo: S align(4) = undefined;
    const ptr: *align(4) S = &foo;
    const ptr_to_b: *u32 = &ptr.b;
}

$ zig test test.zig
./docgen_tmp/test.zig:8:32: error: expected type '*u32', found '*align(1) u32'
    const ptr_to_b: *u32 = &ptr.b;
                               ^

When this bug is fixed, the above test in the documentation will unexpectedly pass, which will cause the test suite to fail, notifying the bug fixer to update these docs.

It's also possible to set alignment of struct fields:

test.zig

const std = @import("std");
const expectEqual = std.testing.expectEqual;

test "aligned struct fields" {
    const S = struct {
        a: u32 align(2),
        b: u32 align(64),
    };
    var foo = S{ .a = 1, .b = 2 };

    try expectEqual(64, @alignOf(S));
    try expectEqual(*align(2) u32, @TypeOf(&foo.a));
    try expectEqual(*align(64) u32, @TypeOf(&foo.b));
}

$ zig test test.zig
Test [1/1] test "aligned struct fields"... 

All 1 tests passed.

Using packed structs with volatile is problematic, and may be a compile error in the future. For details on this subscribe to this issue. TODO update these docs with a recommendation on how to use packed structs with MMIO (the use case for volatile packed structs) once this issue is resolved. Don't worry, there will be a good solution for this use case in zig.

Struct Naming §

Since all structs are anonymous, Zig infers the type name based on a few rules.

• If the struct is in the initialization expression of a variable, it gets named after that variable.
• If the struct is in the return expression, it gets named after the function it is returning from, with the parameter values serialized.
• Otherwise, the struct gets a name such as (anonymous struct at file.zig:7:38).

struct_name.zig

const std = @import("std");

pub fn main() void {
    const Foo = struct {};
    std.debug.print("variable: {s}\n", .{@typeName(Foo)});
    std.debug.print("anonymous: {s}\n", .{@typeName(struct {})});
    std.debug.print("function: {s}\n", .{@typeName(List(i32))});
}

fn List(comptime T: type) type {
    return struct {
        x: T,
    };
}

$ zig build-exe struct_name.zig
$ ./struct_name
variable: Foo
anonymous: struct:6:53
function: List(i32)

Anonymous Struct Literals §

Zig allows omitting the struct type of a literal. When the result is coerced, the struct literal will directly instantiate the result location, with no copy:

struct_result.zig

const std = @import("std");
const expect = std.testing.expect;

const Point = struct {x: i32, y: i32};

test "anonymous struct literal" {
    var pt: Point = .{
        .x = 13,
        .y = 67,
    };
    try expect(pt.x == 13);
    try expect(pt.y == 67);
}

$ zig test struct_result.zig
Test [1/1] test "anonymous struct literal"... 

All 1 tests passed.

The struct type can be inferred. Here the result location does not include a type, and so Zig infers the type:

struct_anon.zig

const std = @import("std");
const expect = std.testing.expect;

test "fully anonymous struct" {
    try dump(.{
        .int = @as(u32, 1234),
        .float = @as(f64, 12.34),
        .b = true,
        .s = "hi",
    });
}

fn dump(args: anytype) !void {
    try expect(args.int == 1234);
    try expect(args.float == 12.34);
    try expect(args.b);
    try expect(args.s[0] == 'h');
    try expect(args.s[1] == 'i');
}

$ zig test struct_anon.zig
Test [1/1] test "fully anonymous struct"... 

All 1 tests passed.

Anonymous structs can be created without specifying field names, and are referred to as "tuples".

The fields are implicitly named using numbers starting from 0. Because their names are integers, the @"0" syntax must be used to access them. Names inside @"" are always recognised as identifiers.

Like arrays, tuples have a .len field, can be indexed and work with the ++ and ** operators. They can also be iterated over with inline for.

tuple.zig

const std = @import("std");
const expect = std.testing.expect;

test "tuple" {
    const values = .{
        @as(u32, 1234),
        @as(f64, 12.34),
        true,
        "hi",
    } ++ .{false} ** 2;
    try expect(values[0] == 1234);
    try expect(values[4] == false);
    inline for (values) |v, i| {
        if (i != 2) continue;
        try expect(v);
    }
    try expect(values.len == 6);
    try expect(values.@"3"[0] == 'h');
}

$ zig test tuple.zig
Test [1/1] test "tuple"... 

All 1 tests passed.

See also:

• comptime
• @fieldParentPtr

enum §

enums.zig

const expect = @import("std").testing.expect;
const mem = @import("std").mem;

// Declare an enum.
const Type = enum {
    ok,
    not_ok,
};

// Declare a specific instance of the enum variant.
const c = Type.ok;

// If you want access to the ordinal value of an enum, you
// can specify the tag type.
const Value = enum(u2) {
    zero,
    one,
    two,
};

// Now you can cast between u2 and Value.
// The ordinal value starts from 0, counting up for each member.
test "enum ordinal value" {
    try expect(@enumToInt(Value.zero) == 0);
    try expect(@enumToInt(Value.one) == 1);
    try expect(@enumToInt(Value.two) == 2);
}

// You can override the ordinal value for an enum.
const Value2 = enum(u32) {
    hundred = 100,
    thousand = 1000,
    million = 1000000,
};
test "set enum ordinal value" {
    try expect(@enumToInt(Value2.hundred) == 100);
    try expect(@enumToInt(Value2.thousand) == 1000);
    try expect(@enumToInt(Value2.million) == 1000000);
}

// Enums can have methods, the same as structs and unions.
// Enum methods are not special, they are only namespaced
// functions that you can call with dot syntax.
const Suit = enum {
    clubs,
    spades,
    diamonds,
    hearts,

    pub fn isClubs(self: Suit) bool {
        return self == Suit.clubs;
    }
};
test "enum method" {
    const p = Suit.spades;
    try expect(!p.isClubs());
}

// An enum variant of different types can be switched upon.
const Foo = enum {
    string,
    number,
    none,
};
test "enum variant switch" {
    const p = Foo.number;
    const what_is_it = switch (p) {
        Foo.string => "this is a string",
        Foo.number => "this is a number",
        Foo.none => "this is a none",
    };
    try expect(mem.eql(u8, what_is_it, "this is a number"));
}

// @typeInfo can be used to access the integer tag type of an enum.
const Small = enum {
    one,
    two,
    three,
    four,
};
test "std.meta.Tag" {
    try expect(@typeInfo(Small).Enum.tag_type == u2);
}

// @typeInfo tells us the field count and the fields names:
test "@typeInfo" {
    try expect(@typeInfo(Small).Enum.fields.len == 4);
    try expect(mem.eql(u8, @typeInfo(Small).Enum.fields[1].name, "two"));
}

// @tagName gives a []const u8 representation of an enum value:
test "@tagName" {
    try expect(mem.eql(u8, @tagName(Small.three), "three"));
}

$ zig test enums.zig
Test [1/7] test "enum ordinal value"... 
Test [2/7] test "set enum ordinal value"... 
Test [3/7] test "enum method"... 
Test [4/7] test "enum variant switch"... 
Test [5/7] test "std.meta.Tag"... 
Test [6/7] test "@typeInfo"... 
Test [7/7] test "@tagName"... 

All 7 tests passed.

See also:

• @typeInfo
• @tagName
• @sizeOf

extern enum §

By default, enums are not guaranteed to be compatible with the C ABI:

test.zig

const Foo = enum { a, b, c };
export fn entry(foo: Foo) void { }

$ zig build-obj test.zig
./docgen_tmp/test.zig:2:22: error: parameter of type 'Foo' not allowed in function with calling convention 'C'
export fn entry(foo: Foo) void { }
                     ^

For a C-ABI-compatible enum, use extern enum:

test.zig

const Foo = extern enum { a, b, c };
export fn entry(foo: Foo) void { }

$ zig build-obj test.zig

Enum Literals §

Enum literals allow specifying the name of an enum field without specifying the enum type:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Color = enum {
    auto,
    off,
    on,
};

test "enum literals" {
    const color1: Color = .auto;
    const color2 = Color.auto;
    try expect(color1 == color2);
}

test "switch using enum literals" {
    const color = Color.on;
    const result = switch (color) {
        .auto => false,
        .on => true,
        .off => false,
    };
    try expect(result);
}

$ zig test test.zig
Test [1/2] test "enum literals"... 
Test [2/2] test "switch using enum literals"... 

All 2 tests passed.

Non-exhaustive enum §

A Non-exhaustive enum can be created by adding a trailing '_' field. It must specify a tag type and cannot consume every enumeration value.

@intToEnum on a non-exhaustive enum cannot fail.

A switch on a non-exhaustive enum can include a '_' prong as an alternative to an else prong with the difference being that it makes it a compile error if all the known tag names are not handled by the switch.

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Number = enum(u8) {
    one,
    two,
    three,
    _,
};

test "switch on non-exhaustive enum" {
    const number = Number.one;
    const result = switch (number) {
        .one => true,
        .two,
        .three => false,
        _ => false,
    };
    try expect(result);
    const is_one = switch (number) {
        .one => true,
        else => false,
    };
    try expect(is_one);
}

$ zig test test.zig
Test [1/1] test "switch on non-exhaustive enum"... 

All 1 tests passed.

union §

A bare union defines a set of possible types that a value can be as a list of fields. Only one field can be active at a time. The in-memory representation of bare unions is not guaranteed. Bare unions cannot be used to reinterpret memory. For that, use @ptrCast, or use an extern union or a packed union which have guaranteed in-memory layout. Accessing the non-active field is safety-checked Undefined Behavior:

test.zig

const Payload = union {
    int: i64,
    float: f64,
    boolean: bool,
};
test "simple union" {
    var payload = Payload{ .int = 1234 };
    payload.float = 12.34;
}

$ zig test test.zig
Test [1/1] test "simple union"... 
thread 11537 panic: access of inactive union field
/home/andy/Downloads/zig/docgen_tmp/test.zig:8:12: 0x20677b in test "simple union" (test)
    payload.float = 12.34;
           ^
/home/andy/Downloads/zig/lib/std/special/test_runner.zig:76:28: 0x22d05a in std.special.main (test)
        } else test_fn.func();
                           ^
/home/andy/Downloads/zig/lib/std/start.zig:471:37: 0x2255ba in std.start.callMain (test)
            const result = root.main() catch |err| {
                                    ^
/home/andy/Downloads/zig/lib/std/start.zig:413:12: 0x20943e in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:332:17: 0x208466 in std.start.posixCallMainAndExit (test)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/andy/Downloads/zig/lib/std/start.zig:245:5: 0x208272 in std.start._start (test)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
error: the following test command crashed:
docgen_tmp/zig-cache/o/333a8741816702dafd0ff99af380ebb1/test /home/andy/Downloads/zig/build-release/zig

You can activate another field by assigning the entire union:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Payload = union {
    int: i64,
    float: f64,
    boolean: bool,
};
test "simple union" {
    var payload = Payload{ .int = 1234 };
    try expect(payload.int == 1234);
    payload = Payload{ .float = 12.34 };
    try expect(payload.float == 12.34);
}

$ zig test test.zig
Test [1/1] test "simple union"... 

All 1 tests passed.

In order to use switch with a union, it must be a Tagged union.

To initialize a union when the tag is a comptime-known name, see @unionInit.

Tagged union §

Unions can be declared with an enum tag type. This turns the union into a tagged union, which makes it eligible to use with switch expressions. Tagged unions coerce to their tag type: Type Coercion: unions and enums.

test.zig

const std = @import("std");
const expect = std.testing.expect;

const ComplexTypeTag = enum {
    ok,
    not_ok,
};
const ComplexType = union(ComplexTypeTag) {
    ok: u8,
    not_ok: void,
};

test "switch on tagged union" {
    const c = ComplexType{ .ok = 42 };
    try expect(@as(ComplexTypeTag, c) == ComplexTypeTag.ok);

    switch (c) {
        ComplexTypeTag.ok => |value| try expect(value == 42),
        ComplexTypeTag.not_ok => unreachable,
    }
}

test "get tag type" {
    try expect(std.meta.Tag(ComplexType) == ComplexTypeTag);
}

test "coerce to enum" {
    const c1 = ComplexType{ .ok = 42 };
    const c2 = ComplexType.not_ok;

    try expect(c1 == .ok);
    try expect(c2 == .not_ok);
}

$ zig test test.zig
Test [1/3] test "switch on tagged union"... 
Test [2/3] test "get tag type"... 
Test [3/3] test "coerce to enum"... 

All 3 tests passed.

In order to modify the payload of a tagged union in a switch expression, place a * before the variable name to make it a pointer:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const ComplexTypeTag = enum {
    ok,
    not_ok,
};
const ComplexType = union(ComplexTypeTag) {
    ok: u8,
    not_ok: void,
};

test "modify tagged union in switch" {
    var c = ComplexType{ .ok = 42 };
    try expect(@as(ComplexTypeTag, c) == ComplexTypeTag.ok);

    switch (c) {
        ComplexTypeTag.ok => |*value| value.* += 1,
        ComplexTypeTag.not_ok => unreachable,
    }

    try expect(c.ok == 43);
}

$ zig test test.zig
Test [1/1] test "modify tagged union in switch"... 

All 1 tests passed.

Unions can be made to infer the enum tag type. Further, unions can have methods just like structs and enums.

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Variant = union(enum) {
    int: i32,
    boolean: bool,

    // void can be omitted when inferring enum tag type.
    none,

    fn truthy(self: Variant) bool {
        return switch (self) {
            Variant.int => |x_int| x_int != 0,
            Variant.boolean => |x_bool| x_bool,
            Variant.none => false,
        };
    }
};

test "union method" {
    var v1 = Variant{ .int = 1 };
    var v2 = Variant{ .boolean = false };

    try expect(v1.truthy());
    try expect(!v2.truthy());
}

$ zig test test.zig
Test [1/1] test "union method"... 

All 1 tests passed.

@tagName can be used to return a comptime []const u8 value representing the field name:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Small2 = union(enum) {
    a: i32,
    b: bool,
    c: u8,
};
test "@tagName" {
    try expect(std.mem.eql(u8, @tagName(Small2.a), "a"));
}

$ zig test test.zig
Test [1/1] test "@tagName"... 

All 1 tests passed.

extern union §

An extern union has memory layout guaranteed to be compatible with the target C ABI.

See also:

• extern struct

packed union §

A packed union has well-defined in-memory layout and is eligible to be in a packed struct.

Anonymous Union Literals §

Anonymous Struct Literals syntax can be used to initialize unions without specifying the type:

anon_union.zig

const std = @import("std");
const expect = std.testing.expect;

const Number = union {
    int: i32,
    float: f64,
};

test "anonymous union literal syntax" {
    var i: Number = .{.int = 42};
    var f = makeNumber();
    try expect(i.int == 42);
    try expect(f.float == 12.34);
}

fn makeNumber() Number {
    return .{.float = 12.34};
}

$ zig test anon_union.zig
Test [1/1] test "anonymous union literal syntax"... 

All 1 tests passed.

opaque §

opaque {} declares a new type with an unknown (but non-zero) size and alignment. It can contain declarations the same as structs, unions, and enums.

This is typically used for type safety when interacting with C code that does not expose struct details. Example:

test.zig

const Derp = opaque {};
const Wat = opaque {};

extern fn bar(d: *Derp) void;
fn foo(w: *Wat) callconv(.C) void {
    bar(w);
}

test "call foo" {
    foo(undefined);
}

$ zig test test.zig
./docgen_tmp/test.zig:6:9: error: expected type '*Derp', found '*Wat'
    bar(w);
        ^
./docgen_tmp/test.zig:6:9: note: pointer type child 'Wat' cannot cast into pointer type child 'Derp'
    bar(w);
        ^

blocks §

Blocks are used to limit the scope of variable declarations:

test.zig

test "access variable after block scope" {
    {
        var x: i32 = 1;
    }
    x += 1;
}

$ zig test test.zig
./docgen_tmp/test.zig:5:5: error: use of undeclared identifier 'x'
    x += 1;
    ^

Blocks are expressions. When labeled, break can be used to return a value from the block:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "labeled break from labeled block expression" {
    var y: i32 = 123;

    const x = blk: {
        y += 1;
        break :blk y;
    };
    try expect(x == 124);
    try expect(y == 124);
}

$ zig test test.zig
Test [1/1] test "labeled break from labeled block expression"... 

All 1 tests passed.

Here, blk can be any name.

See also:

• Labeled while
• Labeled for

Shadowing §

It is never allowed for an identifier to "hide" another one by using the same name:

test.zig

const pi = 3.14;

test "inside test block" {
    // Let's even go inside another block
    {
        var pi: i32 = 1234;
    }
}

$ zig test test.zig
./docgen_tmp/test.zig:6:9: error: redefinition of 'pi'
        var pi: i32 = 1234;
        ^
./docgen_tmp/test.zig:1:1: note: previous definition is here
const pi = 3.14;
^

Because of this, when you read Zig code you can rely on an identifier always meaning the same thing, within the scope it is defined. Note that you can, however use the same name if the scopes are separate:

test.zig

test "separate scopes" {
    {
        const pi = 3.14;
    }
    {
        var pi: bool = true;
    }
}

$ zig test test.zig
Test [1/1] test "separate scopes"... 

All 1 tests passed.

switch §

switch.zig

const std = @import("std");
const expect = std.testing.expect;

test "switch simple" {
    const a: u64 = 10;
    const zz: u64 = 103;

    // All branches of a switch expression must be able to be coerced to a
    // common type.
    //
    // Branches cannot fallthrough. If fallthrough behavior is desired, combine
    // the cases and use an if.
    const b = switch (a) {
        // Multiple cases can be combined via a ','
        1, 2, 3 => 0,

        // Ranges can be specified using the ... syntax. These are inclusive
        // both ends.
        5...100 => 1,

        // Branches can be arbitrarily complex.
        101 => blk: {
            const c: u64 = 5;
            break :blk c * 2 + 1;
        },

        // Switching on arbitrary expressions is allowed as long as the
        // expression is known at compile-time.
        zz => zz,
        comptime blk: {
            const d: u32 = 5;
            const e: u32 = 100;
            break :blk d + e;
        } => 107,

        // The else branch catches everything not already captured.
        // Else branches are mandatory unless the entire range of values
        // is handled.
        else => 9,
    };

    try expect(b == 1);
}

// Switch expressions can be used outside a function:
const os_msg = switch (std.Target.current.os.tag) {
    .linux => "we found a linux user",
    else => "not a linux user",
};

// Inside a function, switch statements implicitly are compile-time
// evaluated if the target expression is compile-time known.
test "switch inside function" {
    switch (std.Target.current.os.tag) {
        .fuchsia => {
            // On an OS other than fuchsia, block is not even analyzed,
            // so this compile error is not triggered.
            // On fuchsia this compile error would be triggered.
            @compileError("fuchsia not supported");
        },
        else => {},
    }
}

$ zig test switch.zig
Test [1/2] test "switch simple"... 
Test [2/2] test "switch inside function"... 

All 2 tests passed.

switch can be used to capture the field values of a Tagged union. Modifications to the field values can be done by placing a * before the capture variable name, turning it into a pointer.

test.zig

const expect = @import("std").testing.expect;

test "switch on tagged union" {
    const Point = struct {
        x: u8,
        y: u8,
    };
    const Item = union(enum) {
        a: u32,
        c: Point,
        d,
        e: u32,
    };

    var a = Item{ .c = Point{ .x = 1, .y = 2 } };

    // Switching on more complex enums is allowed.
    const b = switch (a) {
        // A capture group is allowed on a match, and will return the enum
        // value matched. If the payload types of both cases are the same
        // they can be put into the same switch prong.
        Item.a, Item.e => |item| item,

        // A reference to the matched value can be obtained using `*` syntax.
        Item.c => |*item| blk: {
            item.*.x += 1;
            break :blk 6;
        },

        // No else is required if the types cases was exhaustively handled
        Item.d => 8,
    };

    try expect(b == 6);
    try expect(a.c.x == 2);
}

$ zig test test.zig
Test [1/1] test "switch on tagged union"... 

All 1 tests passed.

See also:

• comptime
• enum
• @compileError
• Compile Variables

Exhaustive Switching §

When a switch expression does not have an else clause, it must exhaustively list all the possible values. Failure to do so is a compile error:

test.zig

const Color = enum {
    auto,
    off,
    on,
};

test "exhaustive switching" {
    const color = Color.off;
    switch (color) {
        Color.auto => {},
        Color.on => {},
    }
}

$ zig test test.zig
./docgen_tmp/test.zig:9:5: error: enumeration value 'Color.off' not handled in switch
    switch (color) {
    ^
./docgen_tmp/test.zig:7:29: note: referenced here
test "exhaustive switching" {
                            ^

Switching with Enum Literals §

Enum Literals can be useful to use with switch to avoid repetitively specifying enum or union types:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const Color = enum {
    auto,
    off,
    on,
};

test "enum literals with switch" {
    const color = Color.off;
    const result = switch (color) {
        .auto => false,
        .on => false,
        .off => true,
    };
    try expect(result);
}

$ zig test test.zig
Test [1/1] test "enum literals with switch"... 

All 1 tests passed.

while §

A while loop is used to repeatedly execute an expression until some condition is no longer true.

while.zig

const expect = @import("std").testing.expect;

test "while basic" {
    var i: usize = 0;
    while (i < 10) {
        i += 1;
    }
    try expect(i == 10);
}

$ zig test while.zig
Test [1/1] test "while basic"... 

All 1 tests passed.

Use break to exit a while loop early.

while.zig

const expect = @import("std").testing.expect;

test "while break" {
    var i: usize = 0;
    while (true) {
        if (i == 10)
            break;
        i += 1;
    }
    try expect(i == 10);
}

$ zig test while.zig
Test [1/1] test "while break"... 

All 1 tests passed.

Use continue to jump back to the beginning of the loop.

while.zig

const expect = @import("std").testing.expect;

test "while continue" {
    var i: usize = 0;
    while (true) {
        i += 1;
        if (i < 10)
            continue;
        break;
    }
    try expect(i == 10);
}

$ zig test while.zig
Test [1/1] test "while continue"... 

All 1 tests passed.

While loops support a continue expression which is executed when the loop is continued. The continue keyword respects this expression.

while.zig

const expect = @import("std").testing.expect;

test "while loop continue expression" {
    var i: usize = 0;
    while (i < 10) : (i += 1) {}
    try expect(i == 10);
}

test "while loop continue expression, more complicated" {
    var i: usize = 1;
    var j: usize = 1;
    while (i * j < 2000) : ({ i *= 2; j *= 3; }) {
        const my_ij = i * j;
        try expect(my_ij < 2000);
    }
}

$ zig test while.zig
Test [1/2] test "while loop continue expression"... 
Test [2/2] test "while loop continue expression, more complicated"... 

All 2 tests passed.

While loops are expressions. The result of the expression is the result of the else clause of a while loop, which is executed when the condition of the while loop is tested as false.

break, like return, accepts a value parameter. This is the result of the while expression. When you break from a while loop, the else branch is not evaluated.

while.zig

const expect = @import("std").testing.expect;

test "while else" {
    try expect(rangeHasNumber(0, 10, 5));
    try expect(!rangeHasNumber(0, 10, 15));
}

fn rangeHasNumber(begin: usize, end: usize, number: usize) bool {
    var i = begin;
    return while (i < end) : (i += 1) {
        if (i == number) {
            break true;
        }
    } else false;
}

$ zig test while.zig
Test [1/1] test "while else"... 

All 1 tests passed.

Labeled while §

When a while loop is labeled, it can be referenced from a break or continue from within a nested loop:

test.zig

test "nested break" {
    outer: while (true) {
        while (true) {
            break :outer;
        }
    }
}

test "nested continue" {
    var i: usize = 0;
    outer: while (i < 10) : (i += 1) {
        while (true) {
            continue :outer;
        }
    }
}

$ zig test test.zig
Test [1/2] test "nested break"... 
Test [2/2] test "nested continue"... 

All 2 tests passed.

while with Optionals §

Just like if expressions, while loops can take an optional as the condition and capture the payload. When null is encountered the loop exits.

When the |x| syntax is present on a while expression, the while condition must have an Optional Type.

The else branch is allowed on optional iteration. In this case, it will be executed on the first null value encountered.

while.zig

const expect = @import("std").testing.expect;

test "while null capture" {
    var sum1: u32 = 0;
    numbers_left = 3;
    while (eventuallyNullSequence()) |value| {
        sum1 += value;
    }
    try expect(sum1 == 3);

    var sum2: u32 = 0;
    numbers_left = 3;
    while (eventuallyNullSequence()) |value| {
        sum2 += value;
    } else {
        try expect(sum2 == 3);
    }
}

var numbers_left: u32 = undefined;
fn eventuallyNullSequence() ?u32 {
    return if (numbers_left == 0) null else blk: {
        numbers_left -= 1;
        break :blk numbers_left;
    };
}

$ zig test while.zig
Test [1/1] test "while null capture"... 

All 1 tests passed.

while with Error Unions §

Just like if expressions, while loops can take an error union as the condition and capture the payload or the error code. When the condition results in an error code the else branch is evaluated and the loop is finished.

When the else |x| syntax is present on a while expression, the while condition must have an Error Union Type.

while.zig

const expect = @import("std").testing.expect;

test "while error union capture" {
    var sum1: u32 = 0;
    numbers_left = 3;
    while (eventuallyErrorSequence()) |value| {
        sum1 += value;
    } else |err| {
        try expect(err == error.ReachedZero);
    }
}

var numbers_left: u32 = undefined;

fn eventuallyErrorSequence() anyerror!u32 {
    return if (numbers_left == 0) error.ReachedZero else blk: {
        numbers_left -= 1;
        break :blk numbers_left;
    };
}

$ zig test while.zig
Test [1/1] test "while error union capture"... 

All 1 tests passed.

inline while §

While loops can be inlined. This causes the loop to be unrolled, which allows the code to do some things which only work at compile time, such as use types as first class values.

test.zig

const expect = @import("std").testing.expect;

test "inline while loop" {
    comptime var i = 0;
    var sum: usize = 0;
    inline while (i < 3) : (i += 1) {
        const T = switch (i) {
            0 => f32,
            1 => i8,
            2 => bool,
            else => unreachable,
        };
        sum += typeNameLength(T);
    }
    try expect(sum == 9);
}

fn typeNameLength(comptime T: type) usize {
    return @typeName(T).len;
}

$ zig test test.zig
Test [1/1] test "inline while loop"... 

All 1 tests passed.

It is recommended to use inline loops only for one of these reasons:

• You need the loop to execute at comptime for the semantics to work.
• You have a benchmark to prove that forcibly unrolling the loop in this way is measurably faster.

See also:

• if
• Optionals
• Errors
• comptime
• unreachable

for §

for.zig

const expect = @import("std").testing.expect;

test "for basics" {
    const items = [_]i32 { 4, 5, 3, 4, 0 };
    var sum: i32 = 0;

    // For loops iterate over slices and arrays.
    for (items) |value| {
        // Break and continue are supported.
        if (value == 0) {
            continue;
        }
        sum += value;
    }
    try expect(sum == 16);

    // To iterate over a portion of a slice, reslice.
    for (items[0..1]) |value| {
        sum += value;
    }
    try expect(sum == 20);

    // To access the index of iteration, specify a second capture value.
    // This is zero-indexed.
    var sum2: i32 = 0;
    for (items) |value, i| {
        try expect(@TypeOf(i) == usize);
        sum2 += @intCast(i32, i);
    }
    try expect(sum2 == 10);
}

test "for reference" {
    var items = [_]i32 { 3, 4, 2 };

    // Iterate over the slice by reference by
    // specifying that the capture value is a pointer.
    for (items) |*value| {
        value.* += 1;
    }

    try expect(items[0] == 4);
    try expect(items[1] == 5);
    try expect(items[2] == 3);
}

test "for else" {
    // For allows an else attached to it, the same as a while loop.
    var items = [_]?i32 { 3, 4, null, 5 };

    // For loops can also be used as expressions.
    // Similar to while loops, when you break from a for loop, the else branch is not evaluated.
    var sum: i32 = 0;
    const result = for (items) |value| {
        if (value != null) {
            sum += value.?;
        }
    } else blk: {
        try expect(sum == 12);
        break :blk sum;
    };
    try expect(result == 12);
}

$ zig test for.zig
Test [1/3] test "for basics"... 
Test [2/3] test "for reference"... 
Test [3/3] test "for else"... 

All 3 tests passed.

Labeled for §

When a for loop is labeled, it can be referenced from a break or continue from within a nested loop:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "nested break" {
    var count: usize = 0;
    outer: for ([_]i32{ 1, 2, 3, 4, 5 }) |_| {
        for ([_]i32{ 1, 2, 3, 4, 5 }) |_| {
            count += 1;
            break :outer;
        }
    }
    try expect(count == 1);
}

test "nested continue" {
    var count: usize = 0;
    outer: for ([_]i32{ 1, 2, 3, 4, 5, 6, 7, 8 }) |_| {
        for ([_]i32{ 1, 2, 3, 4, 5 }) |_| {
            count += 1;
            continue :outer;
        }
    }

    try expect(count == 8);
}

$ zig test test.zig
Test [1/2] test "nested break"... 
Test [2/2] test "nested continue"... 

All 2 tests passed.

inline for §

For loops can be inlined. This causes the loop to be unrolled, which allows the code to do some things which only work at compile time, such as use types as first class values. The capture value and iterator value of inlined for loops are compile-time known.

test.zig

const expect = @import("std").testing.expect;

test "inline for loop" {
    const nums = [_]i32{2, 4, 6};
    var sum: usize = 0;
    inline for (nums) |i| {
        const T = switch (i) {
            2 => f32,
            4 => i8,
            6 => bool,
            else => unreachable,
        };
        sum += typeNameLength(T);
    }
    try expect(sum == 9);
}

fn typeNameLength(comptime T: type) usize {
    return @typeName(T).len;
}

$ zig test test.zig
Test [1/1] test "inline for loop"... 

All 1 tests passed.

It is recommended to use inline loops only for one of these reasons:

• You need the loop to execute at comptime for the semantics to work.
• You have a benchmark to prove that forcibly unrolling the loop in this way is measurably faster.

See also:

• while
• comptime
• Arrays
• Slices

if §

if.zig

// If expressions have three uses, corresponding to the three types:
// * bool
// * ?T
// * anyerror!T

const expect = @import("std").testing.expect;

test "if expression" {
    // If expressions are used instead of a ternary expression.
    const a: u32 = 5;
    const b: u32 = 4;
    const result = if (a != b) 47 else 3089;
    try expect(result == 47);
}

test "if boolean" {
    // If expressions test boolean conditions.
    const a: u32 = 5;
    const b: u32 = 4;
    if (a != b) {
        try expect(true);
    } else if (a == 9) {
        unreachable;
    } else {
        unreachable;
    }
}

test "if optional" {
    // If expressions test for null.

    const a: ?u32 = 0;
    if (a) |value| {
        try expect(value == 0);
    } else {
        unreachable;
    }

    const b: ?u32 = null;
    if (b) |value| {
        unreachable;
    } else {
        try expect(true);
    }

    // The else is not required.
    if (a) |value| {
        try expect(value == 0);
    }

    // To test against null only, use the binary equality operator.
    if (b == null) {
        try expect(true);
    }

    // Access the value by reference using a pointer capture.
    var c: ?u32 = 3;
    if (c) |*value| {
        value.* = 2;
    }

    if (c) |value| {
        try expect(value == 2);
    } else {
        unreachable;
    }
}

test "if error union" {
    // If expressions test for errors.
    // Note the |err| capture on the else.

    const a: anyerror!u32 = 0;
    if (a) |value| {
        try expect(value == 0);
    } else |err| {
        unreachable;
    }

    const b: anyerror!u32 = error.BadValue;
    if (b) |value| {
        unreachable;
    } else |err| {
        try expect(err == error.BadValue);
    }

    // The else and |err| capture is strictly required.
    if (a) |value| {
        try expect(value == 0);
    } else |_| {}

    // To check only the error value, use an empty block expression.
    if (b) |_| {} else |err| {
        try expect(err == error.BadValue);
    }

    // Access the value by reference using a pointer capture.
    var c: anyerror!u32 = 3;
    if (c) |*value| {
        value.* = 9;
    } else |err| {
        unreachable;
    }

    if (c) |value| {
        try expect(value == 9);
    } else |err| {
        unreachable;
    }
}

test "if error union with optional" {
    // If expressions test for errors before unwrapping optionals.
    // The |optional_value| capture's type is ?u32.

    const a: anyerror!?u32 = 0;
    if (a) |optional_value| {
        try expect(optional_value.? == 0);
    } else |err| {
        unreachable;
    }

    const b: anyerror!?u32 = null;
    if (b) |optional_value| {
        try expect(optional_value == null);
    } else |err| {
        unreachable;
    }

    const c: anyerror!?u32 = error.BadValue;
    if (c) |optional_value| {
        unreachable;
    } else |err| {
        try expect(err == error.BadValue);
    }

    // Access the value by reference by using a pointer capture each time.
    var d: anyerror!?u32 = 3;
    if (d) |*optional_value| {
        if (optional_value.*) |*value| {
            value.* = 9;
        }
    } else |err| {
        unreachable;
    }

    if (d) |optional_value| {
        try expect(optional_value.? == 9);
    } else |err| {
        unreachable;
    }
}

$ zig test if.zig
Test [1/5] test "if expression"... 
Test [2/5] test "if boolean"... 
Test [3/5] test "if optional"... 
Test [4/5] test "if error union"... 
Test [5/5] test "if error union with optional"... 

All 5 tests passed.

See also:

• Optionals
• Errors

defer §

defer.zig

const std = @import("std");
const expect = std.testing.expect;
const print = std.debug.print;

// defer will execute an expression at the end of the current scope.
fn deferExample() !usize {
    var a: usize = 1;

    {
        defer a = 2;
        a = 1;
    }
    try expect(a == 2);

    a = 5;
    return a;
}

test "defer basics" {
    try expect((try deferExample()) == 5);
}

// If multiple defer statements are specified, they will be executed in
// the reverse order they were run.
fn deferUnwindExample() void {
    print("\n", .{});

    defer {
        print("1 ", .{});
    }
    defer {
        print("2 ", .{});
    }
    if (false) {
        // defers are not run if they are never executed.
        defer {
            print("3 ", .{});
        }
    }
}

test "defer unwinding" {
    deferUnwindExample();
}

// The errdefer keyword is similar to defer, but will only execute if the
// scope returns with an error.
//
// This is especially useful in allowing a function to clean up properly
// on error, and replaces goto error handling tactics as seen in c.
fn deferErrorExample(is_error: bool) !void {
    print("\nstart of function\n", .{});

    // This will always be executed on exit
    defer {
        print("end of function\n", .{});
    }

    errdefer {
        print("encountered an error!\n", .{});
    }

    if (is_error) {
        return error.DeferError;
    }
}

test "errdefer unwinding" {
    deferErrorExample(false) catch {};
    deferErrorExample(true) catch {};
}

$ zig test defer.zig
Test [1/3] test "defer basics"... 
Test [2/3] test "defer unwinding"... 

2 1 Test [3/3] test "errdefer unwinding"... 

start of function
end of function

start of function
encountered an error!
end of function

All 3 tests passed.

See also:

• Errors

unreachable §

In Debug and ReleaseSafe mode, and when using zig test, unreachable emits a call to panic with the message reached unreachable code.

In ReleaseFast mode, the optimizer uses the assumption that unreachable code will never be hit to perform optimizations. However, zig test even in ReleaseFast mode still emits unreachable as calls to panic.

Basics §

test.zig

// unreachable is used to assert that control flow will never happen upon a
// particular location:
test "basic math" {
    const x = 1;
    const y = 2;
    if (x + y != 3) {
        unreachable;
    }
}

$ zig test test.zig
Test [1/1] test "basic math"... 

All 1 tests passed.

In fact, this is how std.debug.assert is implemented:

test.zig

// This is how std.debug.assert is implemented
fn assert(ok: bool) void {
    if (!ok) unreachable; // assertion failure
}

// This test will fail because we hit unreachable.
test "this will fail" {
    assert(false);
}

$ zig test test.zig
Test [1/1] test "this will fail"... 
thread 12592 panic: reached unreachable code
/home/andy/Downloads/zig/docgen_tmp/test.zig:3:14: 0x207feb in assert (test)
    if (!ok) unreachable; // assertion failure
             ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:8:11: 0x2066de in test "this will fail" (test)
    assert(false);
          ^
/home/andy/Downloads/zig/lib/std/special/test_runner.zig:76:28: 0x22d00a in std.special.main (test)
        } else test_fn.func();
                           ^
/home/andy/Downloads/zig/lib/std/start.zig:471:37: 0x22556a in std.start.callMain (test)
            const result = root.main() catch |err| {
                                    ^
/home/andy/Downloads/zig/lib/std/start.zig:413:12: 0x2093ee in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:332:17: 0x208416 in std.start.posixCallMainAndExit (test)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/andy/Downloads/zig/lib/std/start.zig:245:5: 0x208222 in std.start._start (test)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
error: the following test command crashed:
docgen_tmp/zig-cache/o/333a8741816702dafd0ff99af380ebb1/test /home/andy/Downloads/zig/build-release/zig

At Compile-Time §

test.zig

const assert = @import("std").debug.assert;

test "type of unreachable" {
    comptime {
        // The type of unreachable is noreturn.

        // However this assertion will still fail because
        // evaluating unreachable at compile-time is a compile error.

        assert(@TypeOf(unreachable) == noreturn);
    }
}

$ zig test test.zig
./docgen_tmp/test.zig:10:16: error: unreachable code
        assert(@TypeOf(unreachable) == noreturn);
               ^
./docgen_tmp/test.zig:3:28: note: referenced here
test "type of unreachable" {
                           ^

See also:

• Zig Test
• Build Mode
• comptime

noreturn §

noreturn is the type of:

• break
• continue
• return
• unreachable
• while (true) {}

When resolving types together, such as if clauses or switch prongs, the noreturn type is compatible with every other type. Consider:

test.zig

fn foo(condition: bool, b: u32) void {
    const a = if (condition) b else return;
    @panic("do something with a");
}
test "noreturn" {
    foo(false, 1);
}

$ zig test test.zig
Test [1/1] test "noreturn"... 

All 1 tests passed.

Another use case for noreturn is the exit function:

test.zig

pub extern "kernel32" fn ExitProcess(exit_code: c_uint) callconv(if (@import("builtin").target.cpu.arch == .i386) .Stdcall else .C) noreturn;

test "foo" {
    const value = bar() catch ExitProcess(1);
    try expect(value == 1234);
}

fn bar() anyerror!u32 {
    return 1234;
}

const expect = @import("std").testing.expect;

$ zig test test.zig -target x86_64-windows
warning: created docgen_tmp/zig-cache/o/c42fd17f6f3b779d958fa42345e9399d/test.exe but skipping execution because it is non-native

Functions §

functions.zig

const expect = @import("std").testing.expect;

// Functions are declared like this
fn add(a: i8, b: i8) i8 {
    if (a == 0) {
        return b;
    }

    return a + b;
}

// The export specifier makes a function externally visible in the generated
// object file, and makes it use the C ABI.
export fn sub(a: i8, b: i8) i8 { return a - b; }

// The extern specifier is used to declare a function that will be resolved
// at link time, when linking statically, or at runtime, when linking
// dynamically.
// The callconv specifier changes the calling convention of the function.
extern "kernel32" fn ExitProcess(exit_code: u32) callconv(if (@import("builtin").target.cpu.arch == .i386) .Stdcall else .C) noreturn;
extern "c" fn atan2(a: f64, b: f64) f64;

// The @setCold builtin tells the optimizer that a function is rarely called.
fn abort() noreturn {
    @setCold(true);
    while (true) {}
}

// The naked calling convention makes a function not have any function prologue or epilogue.
// This can be useful when integrating with assembly.
fn _start() callconv(.Naked) noreturn {
    abort();
}

// The inline calling convention forces a function to be inlined at all call sites.
// If the function cannot be inlined, it is a compile-time error.
fn shiftLeftOne(a: u32) callconv(.Inline) u32 {
    return a << 1;
}

// The pub specifier allows the function to be visible when importing.
// Another file can use @import and call sub2
pub fn sub2(a: i8, b: i8) i8 { return a - b; }

// Functions can be used as values and are equivalent to pointers.
const call2_op = fn (a: i8, b: i8) i8;
fn do_op(fn_call: call2_op, op1: i8, op2: i8) i8 {
    return fn_call(op1, op2);
}

test "function" {
    try expect(do_op(add, 5, 6) == 11);
    try expect(do_op(sub2, 5, 6) == -1);
}

$ zig test functions.zig
Test [1/1] test "function"... 

All 1 tests passed.

Function values are like pointers:

test.zig

const assert = @import("std").debug.assert;

comptime {
    assert(@TypeOf(foo) == fn()void);
    assert(@sizeOf(fn()void) == @sizeOf(?fn()void));
}

fn foo() void { }

$ zig build-obj test.zig

Pass-by-value Parameters §

Primitive types such as Integers and Floats passed as parameters are copied, and then the copy is available in the function body. This is called "passing by value". Copying a primitive type is essentially free and typically involves nothing more than setting a register.

Structs, unions, and arrays can sometimes be more efficiently passed as a reference, since a copy could be arbitrarily expensive depending on the size. When these types are passed as parameters, Zig may choose to copy and pass by value, or pass by reference, whichever way Zig decides will be faster. This is made possible, in part, by the fact that parameters are immutable.

test.zig

const Point = struct {
    x: i32,
    y: i32,
};

fn foo(point: Point) i32 {
    // Here, `point` could be a reference, or a copy. The function body
    // can ignore the difference and treat it as a value. Be very careful
    // taking the address of the parameter - it should be treated as if
    // the address will become invalid when the function returns.
    return point.x + point.y;
}

const expect = @import("std").testing.expect;

test "pass struct to function" {
    try expect(foo(Point{ .x = 1, .y = 2 }) == 3);
}

$ zig test test.zig
Test [1/1] test "pass struct to function"... 

All 1 tests passed.

For extern functions, Zig follows the C ABI for passing structs and unions by value.

Function Parameter Type Inference §

Function parameters can be declared with anytype in place of the type. In this case the parameter types will be inferred when the function is called. Use @TypeOf and @typeInfo to get information about the inferred type.

test.zig

const expect = @import("std").testing.expect;

fn addFortyTwo(x: anytype) @TypeOf(x) {
    return x + 42;
}

test "fn type inference" {
    try expect(addFortyTwo(1) == 43);
    try expect(@TypeOf(addFortyTwo(1)) == comptime_int);
    var y: i64 = 2;
    try expect(addFortyTwo(y) == 44);
    try expect(@TypeOf(addFortyTwo(y)) == i64);
}

$ zig test test.zig
Test [1/1] test "fn type inference"... 

All 1 tests passed.

Function Reflection §

test.zig

const expect = @import("std").testing.expect;

test "fn reflection" {
    try expect(@typeInfo(@TypeOf(expect)).Fn.args[0].arg_type.? == bool);
    try expect(@typeInfo(@TypeOf(expect)).Fn.is_var_args == false);
}

$ zig test test.zig
Test [1/1] test "fn reflection"... 

All 1 tests passed.

Errors §

Error Set Type §

An error set is like an enum. However, each error name across the entire compilation gets assigned an unsigned integer greater than 0. You are allowed to declare the same error name more than once, and if you do, it gets assigned the same integer value.

The number of unique error values across the entire compilation should determine the size of the error set type. However right now it is hard coded to be a u16. See #768.

You can coerce an error from a subset to a superset:

test.zig

const std = @import("std");

const FileOpenError = error {
    AccessDenied,
    OutOfMemory,
    FileNotFound,
};

const AllocationError = error {
    OutOfMemory,
};

test "coerce subset to superset" {
    const err = foo(AllocationError.OutOfMemory);
    try std.testing.expect(err == FileOpenError.OutOfMemory);
}

fn foo(err: AllocationError) FileOpenError {
    return err;
}

$ zig test test.zig
Test [1/1] test "coerce subset to superset"... 

All 1 tests passed.

But you cannot coerce an error from a superset to a subset:

test.zig

const FileOpenError = error {
    AccessDenied,
    OutOfMemory,
    FileNotFound,
};

const AllocationError = error {
    OutOfMemory,
};

test "coerce superset to subset" {
    foo(FileOpenError.OutOfMemory) catch {};
}

fn foo(err: FileOpenError) AllocationError {
    return err;
}

$ zig test test.zig
./docgen_tmp/test.zig:16:12: error: expected type 'AllocationError', found 'FileOpenError'
    return err;
           ^
./docgen_tmp/test.zig:2:5: note: 'error.AccessDenied' not a member of destination error set
    AccessDenied,
    ^
./docgen_tmp/test.zig:4:5: note: 'error.FileNotFound' not a member of destination error set
    FileNotFound,
    ^

There is a shortcut for declaring an error set with only 1 value, and then getting that value:

const err = error.FileNotFound;

This is equivalent to:

const err = (error {FileNotFound}).FileNotFound;

This becomes useful when using Inferred Error Sets.

The Global Error Set §

anyerror refers to the global error set. This is the error set that contains all errors in the entire compilation unit. It is a superset of all other error sets and a subset of none of them.

You can coerce any error set to the global one, and you can explicitly cast an error of the global error set to a non-global one. This inserts a language-level assert to make sure the error value is in fact in the destination error set.

The global error set should generally be avoided because it prevents the compiler from knowing what errors are possible at compile-time. Knowing the error set at compile-time is better for generated documentation and helpful error messages, such as forgetting a possible error value in a switch.

Error Union Type §

An error set type and normal type can be combined with the ! binary operator to form an error union type. You are likely to use an error union type more often than an error set type by itself.

Here is a function to parse a string into a 64-bit integer:

test.zig

const std = @import("std");
const maxInt = std.math.maxInt;

pub fn parseU64(buf: []const u8, radix: u8) !u64 {
    var x: u64 = 0;

    for (buf) |c| {
        const digit = charToDigit(c);

        if (digit >= radix) {
            return error.InvalidChar;
        }

        // x *= radix
        if (@mulWithOverflow(u64, x, radix, &x)) {
            return error.Overflow;
        }

        // x += digit
        if (@addWithOverflow(u64, x, digit, &x)) {
            return error.Overflow;
        }
    }

    return x;
}

fn charToDigit(c: u8) u8 {
    return switch (c) {
        '0' ... '9' => c - '0',
        'A' ... 'Z' => c - 'A' + 10,
        'a' ... 'z' => c - 'a' + 10,
        else => maxInt(u8),
    };
}

test "parse u64" {
    const result = try parseU64("1234", 10);
    try std.testing.expect(result == 1234);
}

$ zig test test.zig
Test [1/1] test "parse u64"... 

All 1 tests passed.

Notice the return type is !u64. This means that the function either returns an unsigned 64 bit integer, or an error. We left off the error set to the left of the !, so the error set is inferred.

Within the function definition, you can see some return statements that return an error, and at the bottom a return statement that returns a u64. Both types coerce to anyerror!u64.

What it looks like to use this function varies depending on what you're trying to do. One of the following:

• You want to provide a default value if it returned an error.
• If it returned an error then you want to return the same error.
• You know with complete certainty it will not return an error, so want to unconditionally unwrap it.
• You want to take a different action for each possible error.

catch §

If you want to provide a default value, you can use the catch binary operator:

fn doAThing(str: []u8) void {
    const number = parseU64(str, 10) catch 13;
    // ...
}

In this code, number will be equal to the successfully parsed string, or a default value of 13. The type of the right hand side of the binary catch operator must match the unwrapped error union type, or be of type noreturn.

try §

Let's say you wanted to return the error if you got one, otherwise continue with the function logic:

fn doAThing(str: []u8) !void {
    const number = parseU64(str, 10) catch |err| return err;
    // ...
}

There is a shortcut for this. The try expression:

fn doAThing(str: []u8) !void {
    const number = try parseU64(str, 10);
    // ...
}

try evaluates an error union expression. If it is an error, it returns from the current function with the same error. Otherwise, the expression results in the unwrapped value.

Maybe you know with complete certainty that an expression will never be an error. In this case you can do this:

const number = parseU64("1234", 10) catch unreachable;

Here we know for sure that "1234" will parse successfully. So we put the unreachable value on the right hand side. unreachable generates a panic in Debug and ReleaseSafe modes and undefined behavior in ReleaseFast mode. So, while we're debugging the application, if there was a surprise error here, the application would crash appropriately.

Finally, you may want to take a different action for every situation. For that, we combine the if and switch expression:

fn doAThing(str: []u8) void {
    if (parseU64(str, 10)) |number| {
        doSomethingWithNumber(number);
    } else |err| switch (err) {
        error.Overflow => {
            // handle overflow...
        },
        // we promise that InvalidChar won't happen (or crash in debug mode if it does)
        error.InvalidChar => unreachable,
    }
}

errdefer §

The other component to error handling is defer statements. In addition to an unconditional defer, Zig has errdefer, which evaluates the deferred expression on block exit path if and only if the function returned with an error from the block.

Example:

fn createFoo(param: i32) !Foo {
    const foo = try tryToAllocateFoo();
    // now we have allocated foo. we need to free it if the function fails.
    // but we want to return it if the function succeeds.
    errdefer deallocateFoo(foo);

    const tmp_buf = allocateTmpBuffer() orelse return error.OutOfMemory;
    // tmp_buf is truly a temporary resource, and we for sure want to clean it up
    // before this block leaves scope
    defer deallocateTmpBuffer(tmp_buf);

    if (param > 1337) return error.InvalidParam;

    // here the errdefer will not run since we're returning success from the function.
    // but the defer will run!
    return foo;
}

The neat thing about this is that you get robust error handling without the verbosity and cognitive overhead of trying to make sure every exit path is covered. The deallocation code is always directly following the allocation code.

A couple of other tidbits about error handling:

• These primitives give enough expressiveness that it's completely practical to have failing to check for an error be a compile error. If you really want to ignore the error, you can add catch unreachable and get the added benefit of crashing in Debug and ReleaseSafe modes if your assumption was wrong.
• Since Zig understands error types, it can pre-weight branches in favor of errors not occurring. Just a small optimization benefit that is not available in other languages.

See also:

• defer
• if
• switch

An error union is created with the ! binary operator. You can use compile-time reflection to access the child type of an error union:

test.zig

const expect = @import("std").testing.expect;

test "error union" {
    var foo: anyerror!i32 = undefined;

    // Coerce from child type of an error union:
    foo = 1234;

    // Coerce from an error set:
    foo = error.SomeError;

    // Use compile-time reflection to access the payload type of an error union:
    comptime try expect(@typeInfo(@TypeOf(foo)).ErrorUnion.payload == i32);

    // Use compile-time reflection to access the error set type of an error union:
    comptime try expect(@typeInfo(@TypeOf(foo)).ErrorUnion.error_set == anyerror);
}

$ zig test test.zig
Test [1/1] test "error union"... 

All 1 tests passed.

Merging Error Sets §

Use the || operator to merge two error sets together. The resulting error set contains the errors of both error sets. Doc comments from the left-hand side override doc comments from the right-hand side. In this example, the doc comments for C.PathNotFound is A doc comment.

This is especially useful for functions which return different error sets depending on comptime branches. For example, the Zig standard library uses LinuxFileOpenError || WindowsFileOpenError for the error set of opening files.

test.zig

const A = error{
    NotDir,

    /// A doc comment
    PathNotFound,
};
const B = error{
    OutOfMemory,

    /// B doc comment
    PathNotFound,
};

const C = A || B;

fn foo() C!void {
    return error.NotDir;
}

test "merge error sets" {
    if (foo()) {
        @panic("unexpected");
    } else |err| switch (err) {
        error.OutOfMemory => @panic("unexpected"),
        error.PathNotFound => @panic("unexpected"),
        error.NotDir => {},
    }
}

$ zig test test.zig
Test [1/1] test "merge error sets"... 

All 1 tests passed.

Inferred Error Sets §

Because many functions in Zig return a possible error, Zig supports inferring the error set. To infer the error set for a function, use this syntax:

test.zig

// With an inferred error set
pub fn add_inferred(comptime T: type, a: T, b: T) !T {
    var answer: T = undefined;
    return if (@addWithOverflow(T, a, b, &answer)) error.Overflow else answer;
}

// With an explicit error set
pub fn add_explicit(comptime T: type, a: T, b: T) Error!T {
    var answer: T = undefined;
    return if (@addWithOverflow(T, a, b, &answer)) error.Overflow else answer;
}

const Error = error {
    Overflow,
};

const std = @import("std");

test "inferred error set" {
    if (add_inferred(u8, 255, 1)) |_| unreachable else |err| switch (err) {
        error.Overflow => {}, // ok
    }
}

$ zig test test.zig
Test [1/1] test "inferred error set"... 

All 1 tests passed.

When a function has an inferred error set, that function becomes generic and thus it becomes trickier to do certain things with it, such as obtain a function pointer, or have an error set that is consistent across different build targets. Additionally, inferred error sets are incompatible with recursion.

In these situations, it is recommended to use an explicit error set. You can generally start with an empty error set and let compile errors guide you toward completing the set.

These limitations may be overcome in a future version of Zig.

Error Return Traces §

Error Return Traces show all the points in the code that an error was returned to the calling function. This makes it practical to use try everywhere and then still be able to know what happened if an error ends up bubbling all the way out of your application.

test.zig

pub fn main() !void {
    try foo(12);
}

fn foo(x: i32) !void {
    if (x >= 5) {
        try bar();
    } else {
        try bang2();
    }
}

fn bar() !void {
    if (baz()) {
        try quux();
    } else |err| switch (err) {
        error.FileNotFound => try hello(),
        else => try another(),
    }
}

fn baz() !void {
    try bang1();
}

fn quux() !void {
    try bang2();
}

fn hello() !void {
    try bang2();
}

fn another() !void {
    try bang1();
}

fn bang1() !void {
    return error.FileNotFound;
}

fn bang2() !void {
    return error.PermissionDenied;
}

$ zig build-exe test.zig
$ ./test
error: PermissionDenied
/home/andy/Downloads/zig/docgen_tmp/test.zig:39:5: 0x231632 in bang1 (test)
    return error.FileNotFound;
    ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:23:5: 0x23150f in baz (test)
    try bang1();
    ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:43:5: 0x2314d2 in bang2 (test)
    return error.PermissionDenied;
    ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:31:5: 0x2315ff in hello (test)
    try bang2();
    ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:17:31: 0x23149e in bar (test)
        error.FileNotFound => try hello(),
                              ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:7:9: 0x23138c in foo (test)
        try bar();
        ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:2:5: 0x22a0c4 in main (test)
    try foo(12);
    ^

Look closely at this example. This is no stack trace.

You can see that the final error bubbled up was PermissionDenied, but the original error that started this whole thing was FileNotFound. In the bar function, the code handles the original error code, and then returns another one, from the switch statement. Error Return Traces make this clear, whereas a stack trace would look like this:

test.zig

pub fn main() void {
    foo(12);
}

fn foo(x: i32) void {
    if (x >= 5) {
        bar();
    } else {
        bang2();
    }
}

fn bar() void {
    if (baz()) {
        quux();
    } else {
        hello();
    }
}

fn baz() bool {
    return bang1();
}

fn quux() void {
    bang2();
}

fn hello() void {
    bang2();
}

fn bang1() bool {
    return false;
}

fn bang2() void {
    @panic("PermissionDenied");
}

$ zig build-exe test.zig
$ ./test
thread 13421 panic: PermissionDenied
/home/andy/Downloads/zig/docgen_tmp/test.zig:38:5: 0x232a66 in bang2 (test)
    @panic("PermissionDenied");
    ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:30:10: 0x2331a8 in hello (test)
    bang2();
         ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:17:14: 0x232a4a in bar (test)
        hello();
             ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:7:12: 0x231155 in foo (test)
        bar();
           ^
/home/andy/Downloads/zig/docgen_tmp/test.zig:2:8: 0x229efd in main (test)
    foo(12);
       ^
/home/andy/Downloads/zig/lib/std/start.zig:461:22: 0x2222dc in std.start.callMain (test)
            root.main();
                     ^
/home/andy/Downloads/zig/lib/std/start.zig:413:12: 0x20616e in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:332:17: 0x205196 in std.start.posixCallMainAndExit (test)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/andy/Downloads/zig/lib/std/start.zig:245:5: 0x204fa2 in std.start._start (test)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});
    ^
(process terminated by signal)

Here, the stack trace does not explain how the control flow in bar got to the hello() call. One would have to open a debugger or further instrument the application in order to find out. The error return trace, on the other hand, shows exactly how the error bubbled up.

This debugging feature makes it easier to iterate quickly on code that robustly handles all error conditions. This means that Zig developers will naturally find themselves writing correct, robust code in order to increase their development pace.

Error Return Traces are enabled by default in Debug and ReleaseSafe builds and disabled by default in ReleaseFast and ReleaseSmall builds.

There are a few ways to activate this error return tracing feature:

• Return an error from main
• An error makes its way to catch unreachable and you have not overridden the default panic handler
• Use errorReturnTrace to access the current return trace. You can use std.debug.dumpStackTrace to print it. This function returns comptime-known null when building without error return tracing support.

Implementation Details §

To analyze performance cost, there are two cases:

• when no errors are returned
• when returning errors

For the case when no errors are returned, the cost is a single memory write operation, only in the first non-failable function in the call graph that calls a failable function, i.e. when a function returning void calls a function returning error. This is to initialize this struct in the stack memory:

pub const StackTrace = struct {
    index: usize,
    instruction_addresses: [N]usize,
};

Here, N is the maximum function call depth as determined by call graph analysis. Recursion is ignored and counts for 2.

A pointer to StackTrace is passed as a secret parameter to every function that can return an error, but it's always the first parameter, so it can likely sit in a register and stay there.

That's it for the path when no errors occur. It's practically free in terms of performance.

When generating the code for a function that returns an error, just before the return statement (only for the return statements that return errors), Zig generates a call to this function:

// marked as "no-inline" in LLVM IR
fn __zig_return_error(stack_trace: *StackTrace) void {
    stack_trace.instruction_addresses[stack_trace.index] = @returnAddress();
    stack_trace.index = (stack_trace.index + 1) % N;
}

The cost is 2 math operations plus some memory reads and writes. The memory accessed is constrained and should remain cached for the duration of the error return bubbling.

As for code size cost, 1 function call before a return statement is no big deal. Even so, I have a plan to make the call to __zig_return_error a tail call, which brings the code size cost down to actually zero. What is a return statement in code without error return tracing can become a jump instruction in code with error return tracing.

Optionals §

One area that Zig provides safety without compromising efficiency or readability is with the optional type.

The question mark symbolizes the optional type. You can convert a type to an optional type by putting a question mark in front of it, like this:

// normal integer
const normal_int: i32 = 1234;

// optional integer
const optional_int: ?i32 = 5678;

Now the variable optional_int could be an i32, or null.

Instead of integers, let's talk about pointers. Null references are the source of many runtime exceptions, and even stand accused of being the worst mistake of computer science.

Zig does not have them.

Instead, you can use an optional pointer. This secretly compiles down to a normal pointer, since we know we can use 0 as the null value for the optional type. But the compiler can check your work and make sure you don't assign null to something that can't be null.

Typically the downside of not having null is that it makes the code more verbose to write. But, let's compare some equivalent C code and Zig code.

Task: call malloc, if the result is null, return null.

C code

// malloc prototype included for reference
void *malloc(size_t size);

struct Foo *do_a_thing(void) {
    char *ptr = malloc(1234);
    if (!ptr) return NULL;
    // ...
}

Zig code

// malloc prototype included for reference
extern fn malloc(size: size_t) ?*u8;

fn doAThing() ?*Foo {
    const ptr = malloc(1234) orelse return null;
    // ...
}

Here, Zig is at least as convenient, if not more, than C. And, the type of "ptr" is *u8 not ?*u8. The orelse keyword unwrapped the optional type and therefore ptr is guaranteed to be non-null everywhere it is used in the function.

The other form of checking against NULL you might see looks like this:

void do_a_thing(struct Foo *foo) {
    // do some stuff

    if (foo) {
        do_something_with_foo(foo);
    }

    // do some stuff
}

In Zig you can accomplish the same thing:

fn doAThing(optional_foo: ?*Foo) void {
    // do some stuff

    if (optional_foo) |foo| {
      doSomethingWithFoo(foo);
    }

    // do some stuff
}

Once again, the notable thing here is that inside the if block, foo is no longer an optional pointer, it is a pointer, which cannot be null.

One benefit to this is that functions which take pointers as arguments can be annotated with the "nonnull" attribute - __attribute__((nonnull)) in GCC. The optimizer can sometimes make better decisions knowing that pointer arguments cannot be null.

Optional Type §

An optional is created by putting ? in front of a type. You can use compile-time reflection to access the child type of an optional:

test.zig

const expect = @import("std").testing.expect;

test "optional type" {
    // Declare an optional and coerce from null:
    var foo: ?i32 = null;

    // Coerce from child type of an optional
    foo = 1234;

    // Use compile-time reflection to access the child type of the optional:
    comptime try expect(@typeInfo(@TypeOf(foo)).Optional.child == i32);
}

$ zig test test.zig
Test [1/1] test "optional type"... 

All 1 tests passed.

null §

Just like undefined, null has its own type, and the only way to use it is to cast it to a different type:

const optional_value: ?i32 = null;

Optional Pointers §

An optional pointer is guaranteed to be the same size as a pointer. The null of the optional is guaranteed to be address 0.

test.zig

const expect = @import("std").testing.expect;

test "optional pointers" {
    // Pointers cannot be null. If you want a null pointer, use the optional
    // prefix `?` to make the pointer type optional.
    var ptr: ?*i32 = null;

    var x: i32 = 1;
    ptr = &x;

    try expect(ptr.?.* == 1);

    // Optional pointers are the same size as normal pointers, because pointer
    // value 0 is used as the null value.
    try expect(@sizeOf(?*i32) == @sizeOf(*i32));
}

$ zig test test.zig
Test [1/1] test "optional pointers"... 

All 1 tests passed.

Casting §

A type cast converts a value of one type to another. Zig has Type Coercion for conversions that are known to be completely safe and unambiguous, and Explicit Casts for conversions that one would not want to happen on accident. There is also a third kind of type conversion called Peer Type Resolution for the case when a result type must be decided given multiple operand types.

Type Coercion §

Type coercion occurs when one type is expected, but different type is provided:

test.zig

test "type coercion - variable declaration" {
    var a: u8 = 1;
    var b: u16 = a;
}

test "type coercion - function call" {
    var a: u8 = 1;
    foo(a);
}

fn foo(b: u16) void {}

test "type coercion - @as builtin" {
    var a: u8 = 1;
    var b = @as(u16, a);
}

$ zig test test.zig
Test [1/3] test "type coercion - variable declaration"... 
Test [2/3] test "type coercion - function call"... 
Test [3/3] test "type coercion - @as builtin"... 

All 3 tests passed.

Type coercions are only allowed when it is completely unambiguous how to get from one type to another, and the transformation is guaranteed to be safe. There is one exception, which is C Pointers.

Type Coercion: Stricter Qualification §

Values which have the same representation at runtime can be cast to increase the strictness of the qualifiers, no matter how nested the qualifiers are:

• const - non-const to const is allowed
• volatile - non-volatile to volatile is allowed
• align - bigger to smaller alignment is allowed
• error sets to supersets is allowed

These casts are no-ops at runtime since the value representation does not change.

test.zig

test "type coercion - const qualification" {
    var a: i32 = 1;
    var b: *i32 = &a;
    foo(b);
}

fn foo(a: *const i32) void {}

$ zig test test.zig
Test [1/1] test "type coercion - const qualification"... 

All 1 tests passed.

In addition, pointers coerce to const optional pointers:

test.zig

const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;

test "cast *[1][*]const u8 to [*]const ?[*]const u8" {
    const window_name = [1][*]const u8{"window name"};
    const x: [*]const ?[*]const u8 = &window_name;
    try expect(mem.eql(u8, std.mem.spanZ(@ptrCast([*:0]const u8, x[0].?)), "window name"));
}

$ zig test test.zig
Test [1/1] test "cast *[1][*]const u8 to [*]const ?[*]const u8"... 

All 1 tests passed.

Type Coercion: Integer and Float Widening §

Integers coerce to integer types which can represent every value of the old type, and likewise Floats coerce to float types which can represent every value of the old type.

test.zig

const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;

test "integer widening" {
    var a: u8 = 250;
    var b: u16 = a;
    var c: u32 = b;
    var d: u64 = c;
    var e: u64 = d;
    var f: u128 = e;
    try expect(f == a);
}

test "implicit unsigned integer to signed integer" {
    var a: u8 = 250;
    var b: i16 = a;
    try expect(b == 250);
}

test "float widening" {
    // Note: there is an open issue preventing this from working on aarch64:
    // https://github.com/ziglang/zig/issues/3282
    if (std.Target.current.cpu.arch == .aarch64) return error.SkipZigTest;

    var a: f16 = 12.34;
    var b: f32 = a;
    var c: f64 = b;
    var d: f128 = c;
    try expect(d == a);
}

$ zig test test.zig
Test [1/3] test "integer widening"... 
Test [2/3] test "implicit unsigned integer to signed integer"... 
Test [3/3] test "float widening"... 

All 3 tests passed.

Type Coercion: Coercion Float to Int §

A compiler error is appropriate because this ambiguous expression leaves the compiler two choices about the coercion.

• Cast 54.0 to comptime_int resulting in @as(comptime_int, 10), which is casted to @as(f32, 10)
• Cast 5 to comptime_float resulting in @as(comptime_float, 10.8), which is casted to @as(f32, 10.8)

test.zig

// Compile time coercion of float to int
test "implicit cast to comptime_int" {
    var f: f32 = 54.0 / 5;
}

$ zig test test.zig
./docgen_tmp/test.zig:3:18: error: float value 54.000000 cannot be coerced to type 'comptime_int'
    var f: f32 = 54.0 / 5;
                 ^
./docgen_tmp/test.zig:3:23: note: referenced here
    var f: f32 = 54.0 / 5;
                      ^

Type Coercion: Slices, Arrays and Pointers §

coerce__slices_arrays_and_ptrs.zig

const std = @import("std");
const expect = std.testing.expect;

// You can assign constant pointers to arrays to a slice with
// const modifier on the element type. Useful in particular for
// String literals.
test "*const [N]T to []const T" {
    var x1: []const u8 = "hello";
    var x2: []const u8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };
    try expect(std.mem.eql(u8, x1, x2));

    var y: []const f32 = &[2]f32{ 1.2, 3.4 };
    try expect(y[0] == 1.2);
}

// Likewise, it works when the destination type is an error union.
test "*const [N]T to E![]const T" {
    var x1: anyerror![]const u8 = "hello";
    var x2: anyerror![]const u8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };
    try expect(std.mem.eql(u8, try x1, try x2));

    var y: anyerror![]const f32 = &[2]f32{ 1.2, 3.4 };
    try expect((try y)[0] == 1.2);
}

// Likewise, it works when the destination type is an optional.
test "*const [N]T to ?[]const T" {
    var x1: ?[]const u8 = "hello";
    var x2: ?[]const u8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };
    try expect(std.mem.eql(u8, x1.?, x2.?));

    var y: ?[]const f32 = &[2]f32{ 1.2, 3.4 };
    try expect(y.?[0] == 1.2);
}

// In this cast, the array length becomes the slice length.
test "*[N]T to []T" {
    var buf: [5]u8 = "hello".*;
    const x: []u8 = &buf;
    try expect(std.mem.eql(u8, x, "hello"));

    const buf2 = [2]f32{ 1.2, 3.4 };
    const x2: []const f32 = &buf2;
    try expect(std.mem.eql(f32, x2, &[2]f32{ 1.2, 3.4 }));
}

// Single-item pointers to arrays can be coerced to many-item pointers.
test "*[N]T to [*]T" {
    var buf: [5]u8 = "hello".*;
    const x: [*]u8 = &buf;
    try expect(x[4] == 'o');
    // x[5] would be an uncaught out of bounds pointer dereference!
}

// Likewise, it works when the destination type is an optional.
test "*[N]T to ?[*]T" {
    var buf: [5]u8 = "hello".*;
    const x: ?[*]u8 = &buf;
    try expect(x.?[4] == 'o');
}

// Single-item pointers can be cast to len-1 single-item arrays.
test "*T to *[1]T" {
    var x: i32 = 1234;
    const y: *[1]i32 = &x;
    const z: [*]i32 = y;
    try expect(z[0] == 1234);
}

$ zig test coerce__slices_arrays_and_ptrs.zig
Test [1/7] test "*const [N]T to []const T"... 
Test [2/7] test "*const [N]T to E![]const T"... 
Test [3/7] test "*const [N]T to ?[]const T"... 
Test [4/7] test "*[N]T to []T"... 
Test [5/7] test "*[N]T to [*]T"... 
Test [6/7] test "*[N]T to ?[*]T"... 
Test [7/7] test "*T to *[1]T"... 

All 7 tests passed.

See also:

• C Pointers

Type Coercion: Optionals §

The payload type of Optionals, as well as null, coerce to the optional type.

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "coerce to optionals" {
    const x: ?i32 = 1234;
    const y: ?i32 = null;

    try expect(x.? == 1234);
    try expect(y == null);
}

$ zig test test.zig
Test [1/1] test "coerce to optionals"... 

All 1 tests passed.

It works nested inside the Error Union Type, too:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "coerce to optionals wrapped in error union" {
    const x: anyerror!?i32 = 1234;
    const y: anyerror!?i32 = null;

    try expect((try x).? == 1234);
    try expect((try y) == null);
}

$ zig test test.zig
Test [1/1] test "coerce to optionals wrapped in error union"... 

All 1 tests passed.

Type Coercion: Error Unions §

The payload type of an Error Union Type as well as the Error Set Type coerce to the error union type:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "coercion to error unions" {
    const x: anyerror!i32 = 1234;
    const y: anyerror!i32 = error.Failure;

    try expect((try x) == 1234);
    try std.testing.expectError(error.Failure, y);
}

$ zig test test.zig
Test [1/1] test "coercion to error unions"... 

All 1 tests passed.

Type Coercion: Compile-Time Known Numbers §

When a number is comptime-known to be representable in the destination type, it may be coerced:

test.zig

const std = @import("std");
const expect = std.testing.expect;

test "coercing large integer type to smaller one when value is comptime known to fit" {
    const x: u64 = 255;
    const y: u8 = x;
    try expect(y == 255);
}

$ zig test test.zig
Test [1/1] test "coercing large integer type to smaller one when value is comptime known ... 

All 1 tests passed.

Type Coercion: unions and enums §

Tagged unions can be coerced to enums, and enums can be coerced to tagged unions when they are comptime-known to be a field of the union that has only one possible value, such as void:

test.zig

const std = @import("std");
const expect = std.testing.expect;

const E = enum {
    one,
    two,
    three,
};

const U = union(E) {
    one: i32,
    two: f32,
    three,
};

test "coercion between unions and enums" {
    var u = U{ .two = 12.34 };
    var e: E = u;
    try expect(e == E.two);

    const three = E.three;
    var another_u: U = three;
    try expect(another_u == E.three);
}

$ zig test test.zig
Test [1/1] test "coercion between unions and enums"... 

All 1 tests passed.

See also:

• union
• enum

Type Coercion: Zero Bit Types §

Zero Bit Types may be coerced to single-item Pointers, regardless of const.

TODO document the reasoning for this

TODO document whether vice versa should work and why

test.zig

test "coercion of zero bit types" {
    var x: void = {};
    var y: *void = x;
    //var z: void = y; // TODO
}

$ zig test test.zig
Test [1/1] test "coercion of zero bit types"... 

All 1 tests passed.

Type Coercion: undefined §

undefined can be cast to any type.

Explicit Casts §

Explicit casts are performed via Builtin Functions. Some explicit casts are safe; some are not. Some explicit casts perform language-level assertions; some do not. Some explicit casts are no-ops at runtime; some are not.

• @bitCast - change type but maintain bit representation
• @alignCast - make a pointer have more alignment
• @boolToInt - convert true to 1 and false to 0
• @enumToInt - obtain the integer tag value of an enum or tagged union
• @errSetCast - convert to a smaller error set
• @errorToInt - obtain the integer value of an error code
• @floatCast - convert a larger float to a smaller float
• @floatToInt - obtain the integer part of a float value
• @intCast - convert between integer types
• @intToEnum - obtain an enum value based on its integer tag value
• @intToError - obtain an error code based on its integer value
• @intToFloat - convert an integer to a float value
• @intToPtr - convert an address to a pointer
• @ptrCast - convert between pointer types
• @ptrToInt - obtain the address of a pointer
• @truncate - convert between integer types, chopping off bits

Peer Type Resolution §

Peer Type Resolution occurs in these places:

• switch expressions
• if expressions
• while expressions
• for expressions
• Multiple break statements in a block
• Some binary operations

This kind of type resolution chooses a type that all peer types can coerce into. Here are some examples:

peer_type_resolution.zig

const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;

test "peer resolve int widening" {
    var a: i8 = 12;
    var b: i16 = 34;
    var c = a + b;
    try expect(c == 46);
    try expect(@TypeOf(c) == i16);
}

test "peer resolve arrays of different size to const slice" {
    try expect(mem.eql(u8, boolToStr(true), "true"));
    try expect(mem.eql(u8, boolToStr(false), "false"));
    comptime try expect(mem.eql(u8, boolToStr(true), "true"));
    comptime try expect(mem.eql(u8, boolToStr(false), "false"));
}
fn boolToStr(b: bool) []const u8 {
    return if (b) "true" else "false";
}

test "peer resolve array and const slice" {
    try testPeerResolveArrayConstSlice(true);
    comptime try testPeerResolveArrayConstSlice(true);
}
fn testPeerResolveArrayConstSlice(b: bool) !void {
    const value1 = if (b) "aoeu" else @as([]const u8, "zz");
    const value2 = if (b) @as([]const u8, "zz") else "aoeu";
    try expect(mem.eql(u8, value1, "aoeu"));
    try expect(mem.eql(u8, value2, "zz"));
}

test "peer type resolution: ?T and T" {
    try expect(peerTypeTAndOptionalT(true, false).? == 0);
    try expect(peerTypeTAndOptionalT(false, false).? == 3);
    comptime {
        try expect(peerTypeTAndOptionalT(true, false).? == 0);
        try expect(peerTypeTAndOptionalT(false, false).? == 3);
    }
}
fn peerTypeTAndOptionalT(c: bool, b: bool) ?usize {
    if (c) {
        return if (b) null else @as(usize, 0);
    }

    return @as(usize, 3);
}

test "peer type resolution: *[0]u8 and []const u8" {
    try expect(peerTypeEmptyArrayAndSlice(true, "hi").len == 0);
    try expect(peerTypeEmptyArrayAndSlice(false, "hi").len == 1);
    comptime {
        try expect(peerTypeEmptyArrayAndSlice(true, "hi").len == 0);
        try expect(peerTypeEmptyArrayAndSlice(false, "hi").len == 1);
    }
}
fn peerTypeEmptyArrayAndSlice(a: bool, slice: []const u8) []const u8 {
    if (a) {
        return &[_]u8{};
    }

    return slice[0..1];
}
test "peer type resolution: *[0]u8, []const u8, and anyerror![]u8" {
    {
        var data = "hi".*;
        const slice = data[0..];
        try expect((try peerTypeEmptyArrayAndSliceAndError(true, slice)).len == 0);
        try expect((try peerTypeEmptyArrayAndSliceAndError(false, slice)).len == 1);
    }
    comptime {
        var data = "hi".*;
        const slice = data[0..];
        try expect((try peerTypeEmptyArrayAndSliceAndError(true, slice)).len == 0);
        try expect((try peerTypeEmptyArrayAndSliceAndError(false, slice)).len == 1);
    }
}
fn peerTypeEmptyArrayAndSliceAndError(a: bool, slice: []u8) anyerror![]u8 {
    if (a) {
        return &[_]u8{};
    }

    return slice[0..1];
}

test "peer type resolution: *const T and ?*T" {
    const a = @intToPtr(*const usize, 0x123456780);
    const b = @intToPtr(?*usize, 0x123456780);
    try expect(a == b);
    try expect(b == a);
}