Zig Language Reference

Use the {#syntax#}const{#endsyntax#} keyword to assign a value to an identifier:

{#syntax#}const{#endsyntax#} applies to all of the bytes that the identifier immediately addresses. {#link|Pointers#} have their own const-ness.

If you need a variable that you can modify, use the {#syntax#}var{#endsyntax#} keyword:

Variables must be initialized:

Use {#syntax#}undefined{#endsyntax#} to leave variables uninitialized:

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

In {#link|Debug#} mode, Zig writes {#syntax#}0xaa{#endsyntax#} bytes to undefined memory. This is to catch bugs early, and to help detect use of undefined memory in a debugger.

Code written within one or more {#syntax#}test{#endsyntax#} declarations can be used to ensure behavior meets expectations:

The introducing_zig_test.zig code sample tests the {#link|function|Functions#} {#syntax#}addOne{#endsyntax#} to ensure that it returns {#syntax#}42{#endsyntax#} given the input {#syntax#}41{#endsyntax#}. From this test's perspective, the {#syntax#}addOne{#endsyntax#} function is said to be code under test.

zig test is a tool that creates and runs a test build. By default, it builds and runs an executable program using the default test runner provided by the {#link|Zig Standard Library#} as its main entry point. During the build, {#syntax#}test{#endsyntax#} declarations found while {#link|resolving|Root Source File#} the given Zig source file are included for the default test runner to run and report on.

The shell output shown above displays two lines after the zig test command. These lines are printed to standard error by the default test runner:

Test [1/1] test "expect addOne adds one to 41"...

Lines like this indicate which test, out of the total number of tests, is being run. In this case, [1/1] indicates that the first test, out of a total of one test, is being run. Note that, when the test runner program's standard error is output to the terminal, these lines are cleared when a test succeeds.

All 1 tests passed.

This line indicates the total number of tests that have passed.

Test declarations contain the {#link|keyword|Keyword Reference#} {#syntax#}test{#endsyntax#}, followed by an optional name written as a {#link|string literal|String Literals and Unicode Code Point Literals#}, followed by a {#link|block|blocks#} containing any valid Zig code that is allowed in a {#link|function|Functions#}.

Test declarations are similar to {#link|Functions#}: they have a return type and a block of code. The implicit return type of {#syntax#}test{#endsyntax#} is the {#link|Error Union Type#} {#syntax#}anyerror!void{#endsyntax#}, and it cannot be changed. When a Zig source file is not built using the zig test tool, the test declarations are omitted from the build.

Test declarations can be written in the same file, where code under test is written, or in a separate Zig source file. Since test declarations are top-level declarations, they are order-independent and can be written before or after the code under test.

When the zig test tool is building a test runner, only resolved {#syntax#}test{#endsyntax#} declarations are included in the build. Initially, only the given Zig source file's top-level declarations are resolved. Unless nested containers are referenced from a top-level test declaration, nested container tests will not be resolved.

The code sample below uses the {#syntax#}std.testing.refAllDecls(@This()){#endsyntax#} function call to reference all of the containers that are in the file including the imported Zig source file. The code sample also shows an alternative way to reference containers using the {#syntax#}_ = C;{#endsyntax#} syntax. This syntax tells the compiler to ignore the result of the expression on the right side of the assignment operator.

The default test runner checks for an {#link|error|Errors#} returned from a test. When a test returns an error, the test is considered a failure and its {#link|error return trace|Error Return Traces#} is output to standard error. The total number of failures will be reported after all tests have run.

One way to skip tests is to filter them out by using the zig test command line parameter --test-filter [text]. This makes the test build only include tests whose name contains the supplied filter text. Note that non-named tests are run even when using the --test-filter [text] command line parameter.

To programmatically skip a test, make a {#syntax#}test{#endsyntax#} return the error {#syntax#}error.SkipZigTest{#endsyntax#} and the default test runner will consider the test as being skipped. The total number of skipped tests will be reported after all tests have run.

The default test runner skips tests containing a {#link|suspend point|Async Functions#} while the test is running using the default, blocking IO mode. (The evented IO mode is enabled using the --test-evented-io command line parameter.)

In the code sample above, the test would not be skipped in blocking IO mode if the {#syntax#}nosuspend{#endsyntax#} keyword was used (see {#link|Async and Await#}).

When code allocates {#link|Memory#} using the {#link|Zig Standard Library#}'s testing allocator, {#syntax#}std.testing.allocator{#endsyntax#}, the default test runner will report any leaks that are found from using the testing allocator:

Use the {#link|compile variable|Compile Variables#} {#syntax#}@import("builtin").is_test{#endsyntax#} to detect a test build:

The default test runner and the Zig Standard Library's testing namespace output messages to standard error.

The Zig Standard Library's testing namespace contains useful functions to help you create tests. In addition to the expect function, this document uses a couple of more functions as exemplified here:

The Zig Standard Library also contains functions to compare {#link|Slices#}, strings, and more. See the rest of the {#syntax#}std.testing{#endsyntax#} namespace in the {#link|Zig Standard Library#} for more available functions.

zig test has a few command line parameters which affect the compilation. See zig test --help for a full list.

A variable is a unit of {#link|Memory#} storage.

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

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

Identifiers must start with an alphabetic character or underscore and may be followed by any number of alphanumeric characters or underscores. They must not overlap with any keywords. See {#link|Keyword Reference#}.

If a name that does not fit these requirements is needed, such as for linking with external libraries, the {#syntax#}@""{#endsyntax#} syntax may be used.

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

Container level variables may be declared inside a {#link|struct#}, {#link|union#}, or {#link|enum#}:

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

The {#syntax#}extern{#endsyntax#} keyword or {#link|@extern#} builtin function can be used to link against a variable that is exported from another object. The {#syntax#}export{#endsyntax#} keyword or {#link|@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.

A variable may be specified to be a thread-local variable using the {#syntax#}threadlocal{#endsyntax#} keyword:

For {#link|Single Threaded Builds#}, all thread local variables are treated as regular {#link|Container Level Variables#}.

Thread local variables may not be {#syntax#}const{#endsyntax#}.

Local variables occur inside {#link|Functions#}, {#link|comptime#} blocks, and {#link|@cImport#} blocks.

When a local variable is {#syntax#}const{#endsyntax#}, it means that after initialization, the variable's value will not change. If the initialization value of a {#syntax#}const{#endsyntax#} variable is {#link|comptime#}-known, then the variable is also {#syntax#}comptime{#endsyntax#}-known.

A local variable may be qualified with the {#syntax#}comptime{#endsyntax#} keyword. This causes the variable's value to be {#syntax#}comptime{#endsyntax#}-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 {#syntax#}comptime{#endsyntax#} expression are implicitly {#syntax#}comptime{#endsyntax#} variables.

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.

In this function, values {#syntax#}a{#endsyntax#} and {#syntax#}b{#endsyntax#} are known only at runtime, and thus this division operation is vulnerable to both {#link|Integer Overflow#} and {#link|Division by Zero#}.

Operators such as {#syntax#}+{#endsyntax#} and {#syntax#}-{#endsyntax#} cause undefined behavior on integer overflow. Alternative operators are provided for wrapping and saturating arithmetic on all targets. {#syntax#}+%{#endsyntax#} and {#syntax#}-%{#endsyntax#} perform wrapping arithmetic while {#syntax#}+|{#endsyntax#} and {#syntax#}-|{#endsyntax#} perform saturating arithmetic.

Zig supports arbitrary bit-width integers, referenced by using an identifier of i or u followed by digits. For example, the identifier {#syntax#}i7{#endsyntax#} refers to a signed 7-bit integer. The maximum allowed bit-width of an integer type is {#syntax#}65535{#endsyntax#}. For signed integer types, Zig uses a two's complement representation.

Zig has the following floating point types:

• {#syntax#}f16{#endsyntax#} - IEEE-754-2008 binary16
• {#syntax#}f32{#endsyntax#} - IEEE-754-2008 binary32
• {#syntax#}f64{#endsyntax#} - IEEE-754-2008 binary64
• {#syntax#}f80{#endsyntax#} - IEEE-754-2008 80-bit extended precision
• {#syntax#}f128{#endsyntax#} - IEEE-754-2008 binary128
• {#syntax#}c_longdouble{#endsyntax#} - matches long double for the target C ABI

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

Float literals {#link|coerce|Type Coercion#} to any floating point type, and to any {#link|integer|Integers#} type when there is no fractional component.

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

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

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.

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.

{#syntax#}a + b
a += b{#endsyntax#}

{#syntax#}2 + 5 == 7{#endsyntax#}

{#syntax#}a +% b
a +%= b{#endsyntax#}

{#syntax#}@as(u32, std.math.maxInt(u32)) +% 1 == 0{#endsyntax#}

{#syntax#}a +| b
a +|= b{#endsyntax#}

{#syntax#}@as(u32, std.math.maxInt(u32)) +| 1 == @as(u32, std.math.maxInt(u32)){#endsyntax#}

{#syntax#}a - b
a -= b{#endsyntax#}

{#syntax#}2 - 5 == -3{#endsyntax#}

{#syntax#}a -% b
a -%= b{#endsyntax#}

{#syntax#}@as(u32, 0) -% 1 == std.math.maxInt(u32){#endsyntax#}

{#syntax#}a -| b
a -|= b{#endsyntax#}

{#syntax#}@as(u32, 0) -| 1 == 0{#endsyntax#}

{#syntax#}-a{#endsyntax#}

{#syntax#}-1 == 0 - 1{#endsyntax#}

{#syntax#}-%a{#endsyntax#}

{#syntax#}-%@as(i32, std.math.minInt(i32)) == std.math.minInt(i32){#endsyntax#}

{#syntax#}a * b
a *= b{#endsyntax#}

{#syntax#}2 * 5 == 10{#endsyntax#}

{#syntax#}a *% b
a *%= b{#endsyntax#}

{#syntax#}@as(u8, 200) *% 2 == 144{#endsyntax#}

{#syntax#}a *| b
a *|= b{#endsyntax#}

{#syntax#}@as(u8, 200) *| 2 == 255{#endsyntax#}

{#syntax#}a / b
a /= b{#endsyntax#}

{#syntax#}10 / 5 == 2{#endsyntax#}

{#syntax#}a % b
a %= b{#endsyntax#}

{#syntax#}10 % 3 == 1{#endsyntax#}

{#syntax#}a << b
a <<= b{#endsyntax#}

{#syntax#}1 << 8 == 256{#endsyntax#}

{#syntax#}a <<| b
a <<|= b{#endsyntax#}

{#syntax#}@as(u8, 1) <<| 8 == 255{#endsyntax#}

{#syntax#}a >> b
a >>= b{#endsyntax#}

{#syntax#}10 >> 1 == 5{#endsyntax#}

{#syntax#}a & b
a &= b{#endsyntax#}

{#syntax#}0b011 & 0b101 == 0b001{#endsyntax#}

{#syntax#}a | b
a |= b{#endsyntax#}

{#syntax#}0b010 | 0b100 == 0b110{#endsyntax#}

{#syntax#}a ^ b
a ^= b{#endsyntax#}

{#syntax#}0b011 ^ 0b101 == 0b110{#endsyntax#}

{#syntax#}~a{#endsyntax#}

{#syntax#}~@as(u8, 0b10101111) == 0b01010000{#endsyntax#}

{#syntax#}a orelse b{#endsyntax#}

{#syntax#}const value: ?u32 = null;
const unwrapped = value orelse 1234;
unwrapped == 1234{#endsyntax#}

{#syntax#}a.?{#endsyntax#}

{#syntax#}a orelse unreachable{#endsyntax#}

{#syntax#}const value: ?u32 = 5678;
value.? == 5678{#endsyntax#}

{#syntax#}a catch b
a catch |err| b{#endsyntax#}

{#syntax#}const value: anyerror!u32 = error.Broken;
const unwrapped = value catch 1234;
unwrapped == 1234{#endsyntax#}

{#syntax#}a and b{#endsyntax#}

{#syntax#}(false and true) == false{#endsyntax#}

{#syntax#}a or b{#endsyntax#}

{#syntax#}(false or true) == true{#endsyntax#}

{#syntax#}!a{#endsyntax#}

{#syntax#}!false == true{#endsyntax#}

{#syntax#}a == b{#endsyntax#}

{#syntax#}(1 == 1) == true{#endsyntax#}

{#syntax#}a == null{#endsyntax#}

{#syntax#}const value: ?u32 = null;
value == null{#endsyntax#}

{#syntax#}a != b{#endsyntax#}

{#syntax#}(1 != 1) == false{#endsyntax#}

{#syntax#}a > b{#endsyntax#}

{#syntax#}(2 > 1) == true{#endsyntax#}

{#syntax#}a >= b{#endsyntax#}

{#syntax#}(2 >= 1) == true{#endsyntax#}

{#syntax#}a < b{#endsyntax#}

{#syntax#}(1 < 2) == true{#endsyntax#}>

{#syntax#}a <= b{#endsyntax#}

{#syntax#}(1 <= 2) == true{#endsyntax#}

{#syntax#}a ++ b{#endsyntax#}

{#syntax#}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}){#endsyntax#}

{#syntax#}a ** b{#endsyntax#}

{#syntax#}const mem = @import("std").mem;
const pattern = "ab" ** 3;
mem.eql(u8, pattern, "ababab"){#endsyntax#}

{#syntax#}a.*{#endsyntax#}

{#syntax#}const x: u32 = 1234;
const ptr = &x;
ptr.* == 1234{#endsyntax#}

{#syntax#}&a{#endsyntax#}

{#syntax#}const x: u32 = 1234;
const ptr = &x;
ptr.* == 1234{#endsyntax#}

{#syntax#}a || b{#endsyntax#}

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

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

Similar to {#link|Enum Literals#} and {#link|Anonymous Struct Literals#} the type can be omitted from array literals:

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

Multidimensional arrays can be created by nesting arrays:

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

A vector is a group of booleans, {#link|Integers#}, {#link|Floats#}, or {#link|Pointers#} which are operated on in parallel, using SIMD instructions if possible. Vector types are created with the builtin function {#link|@Vector#}.

Vectors support the same builtin operators as their underlying base types. These operations are performed element-wise, and return a vector of the same length as the input vectors. This includes:

• Arithmetic ({#syntax#}+{#endsyntax#}, {#syntax#}-{#endsyntax#}, {#syntax#}/{#endsyntax#}, {#syntax#}*{#endsyntax#}, {#syntax#}@divFloor{#endsyntax#}, {#syntax#}@sqrt{#endsyntax#}, {#syntax#}@ceil{#endsyntax#}, {#syntax#}@log{#endsyntax#}, etc.)
• Bitwise operators ({#syntax#}>>{#endsyntax#}, {#syntax#}<<{#endsyntax#}, {#syntax#}&{#endsyntax#}, {#syntax#}|{#endsyntax#}, {#syntax#}~{#endsyntax#}, etc.)
• Comparison operators ({#syntax#}<{#endsyntax#}, {#syntax#}>{#endsyntax#}, {#syntax#}=={#endsyntax#}, etc.)

It is prohibited to use a math operator on a mixture of scalars (individual numbers) and vectors. Zig provides the {#link|@splat#} builtin to easily convert from scalars to vectors, and it supports {#link|@reduce#} and array indexing syntax to convert from vectors to scalars. Vectors also support assignment to and from fixed-length arrays with comptime known length.

For rearranging elements within and between vectors, Zig provides the {#link|@shuffle#} and {#link|@select#} functions.

Operations on vectors shorter than the target machine's native SIMD size will typically compile to single SIMD instructions, while vectors longer than the target machine's native SIMD size will compile to multiple SIMD instructions. If a given operation doesn't have SIMD support on the target architecture, the compiler will default to operating on each vector element one at a time. Zig supports any comptime-known vector length up to 2^32-1, although small powers of two (2-64) are most typical. Note that excessively long vector lengths (e.g. 2^20) may result in compiler crashes on current versions of Zig.

TODO talk about C ABI interop
TODO consider suggesting std.MultiArrayList

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

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

These types are closely related to {#link|Arrays#} and {#link|Slices#}:

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

• {#syntax#}[]T{#endsyntax#} - is a slice (a fat pointer, which contains a pointer of type {#syntax#}[*]T{#endsyntax#} and a length).
  • Supports index syntax: {#syntax#}slice[i]{#endsyntax#}
  • Supports slice syntax: {#syntax#}slice[start..end]{#endsyntax#}
  • Supports len property: {#syntax#}slice.len{#endsyntax#}

Use {#syntax#}&x{#endsyntax#} to obtain a single-item pointer:

Zig supports pointer arithmetic. It's better to assign the pointer to {#syntax#}[*]T{#endsyntax#} and increment that variable. For example, directly incrementing the pointer from a slice will corrupt it.

In Zig, we generally prefer {#link|Slices#} rather than {#link|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.

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

To convert an integer address into a pointer, use {#syntax#}@intToPtr{#endsyntax#}. To convert a pointer to an integer, use {#syntax#}@ptrToInt{#endsyntax#}:

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

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 {#syntax#}volatile{#endsyntax#}. In the following code, loads and stores with {#syntax#}mmio_ptr{#endsyntax#} are guaranteed to all happen and in the same order as in source code:

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

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

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 {#link|@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 {#syntax#}1 << 29{#endsyntax#}.

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:

In the same way that a {#syntax#}*i32{#endsyntax#} can be {#link|coerced|Type Coercion#} to a {#syntax#}*const i32{#endsyntax#}, 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:

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

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 {#link|Optional Pointers#} instead. {#link|Optional Pointers#} with {#syntax#}allowzero{#endsyntax#} are not the same size as pointers. In this code example, if the pointer did not have the {#syntax#}allowzero{#endsyntax#} attribute, this would be a {#link|Pointer Cast Invalid Null#} panic:

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

This is one reason we prefer slices to pointers.

The syntax {#syntax#}[:x]T{#endsyntax#} 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 {#syntax#}len{#endsyntax#} index.

Sentinel-terminated slices can also be created using a variation of the slice syntax {#syntax#}data[start..end :x]{#endsyntax#}, where {#syntax#}data{#endsyntax#} is a many-item pointer, array or slice and {#syntax#}x{#endsyntax#} is the sentinel value.

Sentinel-terminated slicing asserts that the element in the sentinel position of the backing data is actually the sentinel value. If this is not the case, safety-protected {#link|Undefined Behavior#} results.

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

An {#syntax#}extern struct{#endsyntax#} 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 {#link|packed struct#} or normal {#link|struct#}.

Unlike normal structs, {#syntax#}packed{#endsyntax#} structs have guaranteed in-memory layout:

• Fields remain in the order declared.
• There is no padding between fields.
• Zig supports arbitrary width {#link|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.
• {#syntax#}bool{#endsyntax#} fields use exactly 1 bit.
• An {#link|enum#} field uses exactly the bit width of its integer tag type.
• A {#link|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 {#syntax#}packed struct{#endsyntax#} can participate in a {#link|@bitCast#} or a {#link|@ptrCast#} to reinterpret memory. This even works at {#link|comptime#}:

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

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

In this case, the function {#syntax#}bar{#endsyntax#} cannot be called because 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:

This can be observed with {#link|@bitOffsetOf#} and {#link|offsetOf#}:

Packed structs have the same alignment as their backing integer, however, overaligned pointers to packed structs can override this:

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:

Using packed structs with {#link|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.

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 {#syntax#}return{#endsyntax#} 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).
• If the struct is declared inside another struct, it gets named after both the parent struct and the name inferred by the previous rules, separated by a dot.

Zig allows omitting the struct type of a literal. When the result is {#link|coerced|Type Coercion#}, the struct literal will directly instantiate the result location, with no copy:

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

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 {#syntax#}@"0"{#endsyntax#} syntax must be used to access them. Names inside {#syntax#}@""{#endsyntax#} are always recognised as {#link|identifiers|Identifiers#}.

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

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

For a C-ABI-compatible enum, provide an explicit tag type to the enum:

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

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

{#link|@intToEnum#} on a non-exhaustive enum involves the safety semantics of {#link|@intCast#} to the integer tag type, but beyond that always results in a well-defined enum value.

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

A bare {#syntax#}union{#endsyntax#} 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 {#link|@ptrCast#}, or use an {#link|extern union#} or a {#link|packed union#} which have guaranteed in-memory layout. {#link|Accessing the non-active field|Wrong Union Field Access#} is safety-checked {#link|Undefined Behavior#}:

You can activate another field by assigning the entire union:

In order to use {#link|switch#} with a union, it must be a {#link|Tagged union#}.

To initialize a union when the tag is a {#link|comptime#}-known name, see {#link|@unionInit#}.

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

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

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

{#link|@tagName#} can be used to return a {#link|comptime#} {#syntax#}[:0]const u8{#endsyntax#} value representing the field name:

An {#syntax#}extern union{#endsyntax#} has memory layout guaranteed to be compatible with the target C ABI.

A {#syntax#}packed union{#endsyntax#} has well-defined in-memory layout and is eligible to be in a {#link|packed struct#}.

{#link|Anonymous Struct Literals#} syntax can be used to initialize unions without specifying the type:

{#syntax#}opaque {}{#endsyntax#} declares a new type with an unknown (but non-zero) size and alignment. It can contain declarations the same as {#link|structs|struct#}, {#link|unions|union#}, and {#link|enums|enum#}.

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

Blocks are used to limit the scope of variable declarations:

Blocks are expressions. When labeled, {#syntax#}break{#endsyntax#} can be used to return a value from the block:

Here, {#syntax#}blk{#endsyntax#} can be any name.

{#link|Identifiers#} are never allowed to "hide" other identifiers by using the same name:

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

{#syntax#}switch{#endsyntax#} can be used to capture the field values of a {#link|Tagged union#}. Modifications to the field values can be done by placing a {#syntax#}*{#endsyntax#} before the capture variable name, turning it into a pointer.

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

{#link|Enum Literals#} can be useful to use with {#syntax#}switch{#endsyntax#} to avoid repetitively specifying {#link|enum#} or {#link|union#} types:

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

Use {#syntax#}break{#endsyntax#} to exit a while loop early.

Use {#syntax#}continue{#endsyntax#} to jump back to the beginning of the loop.

While loops support a continue expression which is executed when the loop is continued. The {#syntax#}continue{#endsyntax#} keyword respects this expression.

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

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

When a {#syntax#}while{#endsyntax#} loop is labeled, it can be referenced from a {#syntax#}break{#endsyntax#} or {#syntax#}continue{#endsyntax#} from within a nested loop:

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

When the {#syntax#}|x|{#endsyntax#} syntax is present on a {#syntax#}while{#endsyntax#} expression, the while condition must have an {#link|Optional Type#}.

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

Just like {#link|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 {#syntax#}else |x|{#endsyntax#} syntax is present on a {#syntax#}while{#endsyntax#} expression, the while condition must have an {#link|Error Union Type#}.

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.

It is recommended to use {#syntax#}inline{#endsyntax#} loops only for one of these reasons:

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

When a {#syntax#}for{#endsyntax#} loop is labeled, it can be referenced from a {#syntax#}break{#endsyntax#} or {#syntax#}continue{#endsyntax#} from within a nested loop:

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.

It is recommended to use {#syntax#}inline{#endsyntax#} loops only for one of these reasons:

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

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

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

In fact, this is how {#syntax#}std.debug.assert{#endsyntax#} is implemented:

{#syntax#}noreturn{#endsyntax#} is the type of:

• {#syntax#}break{#endsyntax#}
• {#syntax#}continue{#endsyntax#}
• {#syntax#}return{#endsyntax#}
• {#syntax#}unreachable{#endsyntax#}
• {#syntax#}while (true) {}{#endsyntax#}

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

Another use case for {#syntax#}noreturn{#endsyntax#} is the {#syntax#}exit{#endsyntax#} function:

There is a difference between a function body and a function pointer. Function bodies are {#link|comptime#}-only types while function {#link|Pointers#} may be runtime-known.

Primitive types such as {#link|Integers#} and {#link|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.

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

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

An error set is like an {#link|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 {#syntax#}u16{#endsyntax#}. See #768.

You can {#link|coerce|Type Coercion#} an error from a subset to a superset:

But you cannot {#link|coerce|Type Coercion#} an error from a superset to a subset:

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

This is equivalent to:

This becomes useful when using {#link|Inferred Error Sets#}.

{#syntax#}anyerror{#endsyntax#} 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 {#link|coerce|Type Coercion#} 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 {#link|switch#}.

An error set type and normal type can be combined with the {#syntax#}!{#endsyntax#} 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:

Notice the return type is {#syntax#}!u64{#endsyntax#}. 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 {#syntax#}!{#endsyntax#}, 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 {#syntax#}u64{#endsyntax#}. Both types {#link|coerce|Type Coercion#} to {#syntax#}anyerror!u64{#endsyntax#}.

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.

If you want to provide a default value, you can use the {#syntax#}catch{#endsyntax#} binary operator:

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

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

There is a shortcut for this. The {#syntax#}try{#endsyntax#} expression:

{#syntax#}try{#endsyntax#} 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:

Here we know for sure that "1234" will parse successfully. So we put the {#syntax#}unreachable{#endsyntax#} value on the right hand side. {#syntax#}unreachable{#endsyntax#} 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 {#link|if#} and {#link|switch#} expression:

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

Example:

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.

It should be noted that {#syntax#}errdefer{#endsyntax#} statements only last until the end of the block they are written in, and therefore are not run if an error is returned outside of that block:

To ensure that {#syntax#}deallocateFoo{#endsyntax#} is properly called when returning an error, you must add an {#syntax#}errdefer{#endsyntax#} outside of the block: {#code_begin|test|test_errdefer_block#} const std = @import("std"); const Allocator = std.mem.Allocator; const Foo = struct { data: u32, }; fn tryToAllocateFoo(allocator: Allocator) !*Foo { return allocator.create(Foo); } fn deallocateFoo(allocator: Allocator, foo: *Foo) void { allocator.destroy(foo); } fn getFooData() !u32 { return 666; } fn createFoo(allocator: Allocator, param: i32) !*Foo { const foo = getFoo: { var foo = try tryToAllocateFoo(allocator); errdefer deallocateFoo(allocator, foo); foo.data = try getFooData(); break :getFoo foo; }; // This lasts for the rest of the function errdefer deallocateFoo(allocator, foo); // Error is now properly handled by errdefer if (param > 1337) return error.InvalidParam; return foo; } test "createFoo" { try std.testing.expectError(error.InvalidParam, createFoo(std.testing.allocator, 2468)); } {#code_end#}

The fact that errdefers only last for the block they are declared in is especially important when using loops:

Special care must be taken with code that allocates in a loop to make sure that no memory is leaked when returning an error:

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 {#syntax#}catch unreachable{#endsyntax#} 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.

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

Use the {#syntax#}||{#endsyntax#} 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 {#syntax#}C.PathNotFound{#endsyntax#} is A doc comment.

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

Because many functions in Zig return a possible error, Zig supports inferring the error set. To infer the error set for a function, prepend the {#syntax#}!{#endsyntax#} operator to the function’s return type, like {#syntax#}!T{#endsyntax#}:

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 show all the points in the code that an error was returned to the calling function. This makes it practical to use {#link|try#} everywhere and then still be able to know what happened if an error ends up bubbling all the way out of your application.

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

You can see that the final error bubbled up was {#syntax#}PermissionDenied{#endsyntax#}, but the original error that started this whole thing was {#syntax#}FileNotFound{#endsyntax#}. In the {#syntax#}bar{#endsyntax#} 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:

Here, the stack trace does not explain how the control flow in {#syntax#}bar{#endsyntax#} got to the {#syntax#}hello(){#endsyntax#} 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 {#link|Debug#} and {#link|ReleaseSafe#} builds and disabled by default in {#link|ReleaseFast#} and {#link|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 {#syntax#}catch unreachable{#endsyntax#} and you have not overridden the default panic handler
• Use {#link|errorReturnTrace#} to access the current return trace. You can use {#syntax#}std.debug.dumpStackTrace{#endsyntax#} to print it. This function returns comptime-known {#link|null#} when building without error return tracing support.

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 {#syntax#}void{#endsyntax#} calls a function returning {#syntax#}error{#endsyntax#}. This is to initialize this struct in the stack memory:

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

A pointer to {#syntax#}StackTrace{#endsyntax#} 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 {#syntax#}return{#endsyntax#} statement (only for the {#syntax#}return{#endsyntax#} statements that return errors), Zig generates a call to this function:

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 {#syntax#}__zig_return_error{#endsyntax#} 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.

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:

Now the variable {#syntax#}optional_int{#endsyntax#} could be an {#syntax#}i32{#endsyntax#}, or {#syntax#}null{#endsyntax#}.

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

Zig code

Here, Zig is at least as convenient, if not more, than C. And, the type of "ptr" is {#syntax#}*u8{#endsyntax#} not {#syntax#}?*u8{#endsyntax#}. The {#syntax#}orelse{#endsyntax#} keyword unwrapped the optional type and therefore {#syntax#}ptr{#endsyntax#} 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:

In Zig you can accomplish the same thing:

Once again, the notable thing here is that inside the if block, {#syntax#}foo{#endsyntax#} 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.

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

Just like {#link|undefined#}, {#syntax#}null{#endsyntax#} has its own type, and the only way to use it is to cast it to a different type:

An optional pointer is guaranteed to be the same size as a pointer. The {#syntax#}null{#endsyntax#} of the optional is guaranteed to be address 0.

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

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

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 {#link|C Pointers#}.

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:

• {#syntax#}const{#endsyntax#} - non-const to const is allowed
• {#syntax#}volatile{#endsyntax#} - non-volatile to volatile is allowed
• {#syntax#}align{#endsyntax#} - bigger to smaller alignment is allowed
• {#link|error sets|Error Set Type#} to supersets is allowed

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

In addition, pointers coerce to const optional pointers:

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

A compiler error is appropriate because this ambiguous expression leaves the compiler two choices about the coercion.

• Cast {#syntax#}54.0{#endsyntax#} to {#syntax#}comptime_int{#endsyntax#} resulting in {#syntax#}@as(comptime_int, 10){#endsyntax#}, which is casted to {#syntax#}@as(f32, 10){#endsyntax#}
• Cast {#syntax#}5{#endsyntax#} to {#syntax#}comptime_float{#endsyntax#} resulting in {#syntax#}@as(comptime_float, 10.8){#endsyntax#}, which is casted to {#syntax#}@as(f32, 10.8){#endsyntax#}

The payload type of {#link|Optionals#}, as well as {#link|null#}, coerce to the optional type.

It works nested inside the {#link|Error Union Type#}, too:

The payload type of an {#link|Error Union Type#} as well as the {#link|Error Set Type#} coerce to the error union type:

When a number is {#link|comptime#}-known to be representable in the destination type, it may be coerced:

Tagged unions can be coerced to enums, and enums can be coerced to tagged unions when they are {#link|comptime#}-known to be a field of the union that has only one possible value, such as {#link|void#}:

{#link|undefined#} can be cast to any type.

Explicit casts are performed via {#link|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.

• {#link|@bitCast#} - change type but maintain bit representation
• {#link|@alignCast#} - make a pointer have more alignment
• {#link|@boolToInt#} - convert true to 1 and false to 0
• {#link|@enumToInt#} - obtain the integer tag value of an enum or tagged union
• {#link|@errSetCast#} - convert to a smaller error set
• {#link|@errorToInt#} - obtain the integer value of an error code
• {#link|@floatCast#} - convert a larger float to a smaller float
• {#link|@floatToInt#} - obtain the integer part of a float value
• {#link|@intCast#} - convert between integer types
• {#link|@intToEnum#} - obtain an enum value based on its integer tag value
• {#link|@intToError#} - obtain an error code based on its integer value
• {#link|@intToFloat#} - convert an integer to a float value
• {#link|@intToPtr#} - convert an address to a pointer
• {#link|@ptrCast#} - convert between pointer types
• {#link|@ptrToInt#} - obtain the address of a pointer
• {#link|@truncate#} - convert between integer types, chopping off bits

Peer Type Resolution occurs in these places:

• {#link|switch#} expressions
• {#link|if#} expressions
• {#link|while#} expressions
• {#link|for#} expressions
• Multiple break statements in a block
• Some {#link|binary operations|Table of Operators#}

This kind of type resolution chooses a type that all peer types can coerce into. Here are some examples:

For some types, {#link|@sizeOf#} is 0:

• {#link|void#}
• The {#link|Integers#} {#syntax#}u0{#endsyntax#} and {#syntax#}i0{#endsyntax#}.
• {#link|Arrays#} and {#link|Vectors#} with len 0, or with an element type that is a zero bit type.
• An {#link|enum#} with only 1 tag.
• A {#link|struct#} with all fields being zero bit types.
• A {#link|union#} with only 1 field which is a zero bit type.

These types can only ever have one possible value, and thus require 0 bits to represent. Code that makes use of these types is not included in the final generated code:

When this turns into machine code, there is no code generated in the body of {#syntax#}entry{#endsyntax#}, even in {#link|Debug#} mode. For example, on x86_64:

0000000000000010 <entry>:
  10:	55                   	push   %rbp
  11:	48 89 e5             	mov    %rsp,%rbp
  14:	5d                   	pop    %rbp
  15:	c3                   	retq   

These assembly instructions do not have any code associated with the void values - they only perform the function call prologue and epilog.

{#syntax#}void{#endsyntax#} can be useful for instantiating generic types. For example, given a {#syntax#}Map(Key, Value){#endsyntax#}, one can pass {#syntax#}void{#endsyntax#} for the {#syntax#}Value{#endsyntax#} type to make it into a {#syntax#}Set{#endsyntax#}:

Note that this is different from using a dummy value for the hash map value. By using {#syntax#}void{#endsyntax#} as the type of the value, the hash map entry type has no value field, and thus the hash map takes up less space. Further, all the code that deals with storing and loading the value is deleted, as seen above.

{#syntax#}void{#endsyntax#} is distinct from {#syntax#}anyopaque{#endsyntax#}. {#syntax#}void{#endsyntax#} has a known size of 0 bytes, and {#syntax#}anyopaque{#endsyntax#} has an unknown, but non-zero, size.

Expressions of type {#syntax#}void{#endsyntax#} are the only ones whose value can be ignored. For example:

However, if the expression has type {#syntax#}void{#endsyntax#}, there will be no error. Function return values can also be explicitly ignored by assigning them to {#syntax#}_{#endsyntax#}.

TODO add documentation for this

{#syntax#}usingnamespace{#endsyntax#} is a declaration that mixes all the public declarations of the operand, which must be a {#link|struct#}, {#link|union#}, {#link|enum#}, or {#link|opaque#}, into the namespace:

{#syntax#}usingnamespace{#endsyntax#} has an important use case when organizing the public API of a file or package. For example, one might have c.zig with all of the {#link|C imports|Import from C Header File#}:

The above example demonstrates using {#syntax#}pub{#endsyntax#} to qualify the {#syntax#}usingnamespace{#endsyntax#} additionally makes the imported declarations {#syntax#}pub{#endsyntax#}. This can be used to forward declarations, giving precise control over what declarations a given file exposes.

Zig places importance on the concept of whether an expression is known at compile-time. There are a few different places this concept is used, and these building blocks are used to keep the language small, readable, and powerful.

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

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

A {#syntax#}comptime{#endsyntax#} parameter means that:

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

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

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

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

For example:

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

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

This means that the actual function generated for {#syntax#}max{#endsyntax#} in this situation looks like this:

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

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

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

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

For example:

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

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

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

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

Within a {#syntax#}comptime{#endsyntax#} expression:

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

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

Let's look at an example:

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

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

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

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

What if we fix the base case, but put the wrong value in the {#syntax#}expect{#endsyntax#} line?

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

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

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

Note that we did not have to do anything special with the syntax of these functions. For example, we could call the {#syntax#}sum{#endsyntax#} function as is with a slice of numbers whose length and values were only known at run-time.

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

Here is an example of a generic {#syntax#}List{#endsyntax#} data structure.

That's it. It's a function that returns an anonymous {#syntax#}struct{#endsyntax#}. To keep the language small and uniform, all aggregate types in Zig are anonymous. For the purposes of error messages and debugging, Zig infers the name {#syntax#}"List(i32)"{#endsyntax#} from the function name and parameters invoked when creating the anonymous struct.

To explicitly give a type a name, we assign it to a constant.

In this example, the {#syntax#}Node{#endsyntax#} struct refers to itself. This works because all top level declarations are order-independent. As long as the compiler can determine the size of the struct, it is free to refer to itself. In this case, {#syntax#}Node{#endsyntax#} refers to itself as a pointer, which has a well-defined size at compile time, so it works fine.

Putting all of this together, let's see how {#syntax#}print{#endsyntax#} works in Zig.

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

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

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

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

{#syntax#}printValue{#endsyntax#} is a function that takes a parameter of any type, and does different things depending on the type:

And now, what happens if we give too many arguments to {#syntax#}print{#endsyntax#}?

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

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

This works fine.

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

For some use cases, it may be necessary to directly control the machine code generated by Zig programs, rather than relying on Zig's code generation. For these cases, one can use inline assembly. Here is an example of implementing Hello, World on x86_64 Linux using inline assembly:

Dissecting the syntax:

For i386 and x86_64 targets, the syntax is AT&T syntax, rather than the more popular Intel syntax. This is due to technical constraints; assembly parsing is provided by LLVM and its support for Intel syntax is buggy and not well tested.

Some day Zig may have its own assembler. This would allow it to integrate more seamlessly into the language, as well as be compatible with the popular NASM syntax. This documentation section will be updated before 1.0.0 is released, with a conclusive statement about the status of AT&T vs Intel/NASM syntax.

Output constraints are still considered to be unstable in Zig, and so LLVM documentation and GCC documentation must be used to understand the semantics.

Note that some breaking changes to output constraints are planned with issue #215.

Input constraints are still considered to be unstable in Zig, and so LLVM documentation and GCC documentation must be used to understand the semantics.

Note that some breaking changes to input constraints are planned with issue #215.

Clobbers are the set of registers whose values will not be preserved by the execution of the assembly code. These do not include output or input registers. The special clobber value of {#syntax#}"memory"{#endsyntax#} means that the assembly causes writes to arbitrary undeclared memory locations - not only the memory pointed to by a declared indirect output.

Failure to declare the full set of clobbers for a given inline assembly expression is unchecked {#link|Undefined Behavior#}.

When an assembly expression occurs in a container level {#link|comptime#} block, this is global assembly.

This kind of assembly has different rules than inline assembly. First, {#syntax#}volatile{#endsyntax#} is not valid because all global assembly is unconditionally included. Second, there are no inputs, outputs, or clobbers. All global assembly is concatenated verbatim into one long string and assembled together. There are no template substitution rules regarding % as there are in inline assembly expressions.

TODO: @fence()

TODO: @atomic rmw

TODO: builtin atomic memory ordering enum

When a function is called, a frame is pushed to the stack, the function runs until it reaches a return statement, and then the frame is popped from the stack. The code following the callsite does not run until the function returns.

An async function is a function whose execution is split into an {#syntax#}async{#endsyntax#} initiation, followed by an {#syntax#}await{#endsyntax#} completion. Its frame is provided explicitly by the caller, and it can be suspended and resumed any number of times.

The code following the {#syntax#}async{#endsyntax#} callsite runs immediately after the async function first suspends. When the return value of the async function is needed, the calling code can {#syntax#}await{#endsyntax#} on the async function frame. This will suspend the calling code until the async function completes, at which point execution resumes just after the {#syntax#}await{#endsyntax#} callsite.

Zig infers that a function is {#syntax#}async{#endsyntax#} when it observes that the function contains a suspension point. Async functions can be called the same as normal functions. A function call of an async function is a suspend point.

At any point, a function may suspend itself. This causes control flow to return to the callsite (in the case of the first suspension), or resumer (in the case of subsequent suspensions).

In the same way that each allocation should have a corresponding free, Each {#syntax#}suspend{#endsyntax#} should have a corresponding {#syntax#}resume{#endsyntax#}. A suspend block allows a function to put a pointer to its own frame somewhere, for example into an event loop, even if that action will perform a {#syntax#}resume{#endsyntax#} operation on a different thread. {#link|@frame#} provides access to the async function frame pointer.

{#syntax#}suspend{#endsyntax#} causes a function to be {#syntax#}async{#endsyntax#}.

Upon entering a {#syntax#}suspend{#endsyntax#} block, the async function is already considered suspended, and can be resumed. For example, if you started another kernel thread, and had that thread call {#syntax#}resume{#endsyntax#} on the frame pointer provided by the {#link|@frame#}, the new thread would begin executing after the suspend block, while the old thread continued executing the suspend block.

However, the async function can be directly resumed from the suspend block, in which case it never returns to its resumer and continues executing.

This is guaranteed to tail call, and therefore will not cause a new stack frame.

In the same way that every {#syntax#}suspend{#endsyntax#} has a matching {#syntax#}resume{#endsyntax#}, every {#syntax#}async{#endsyntax#} has a matching {#syntax#}await{#endsyntax#} in standard code.

However, it is possible to have an {#syntax#}async{#endsyntax#} call without a matching {#syntax#}await{#endsyntax#}. Upon completion of the async function, execution would continue at the most recent {#syntax#}async{#endsyntax#} callsite or {#syntax#}resume{#endsyntax#} callsite, and the return value of the async function would be lost.

The {#syntax#}await{#endsyntax#} keyword is used to coordinate with an async function's {#syntax#}return{#endsyntax#} statement.

{#syntax#}await{#endsyntax#} is a suspend point, and takes as an operand anything that coerces to {#syntax#}anyframe->T{#endsyntax#}. Calling {#syntax#}await{#endsyntax#} on the frame of an async function will cause execution to continue at the {#syntax#}await{#endsyntax#} callsite once the target function completes.

There is a common misconception that {#syntax#}await{#endsyntax#} resumes the target function. It is the other way around: it suspends until the target function completes. In the event that the target function has already completed, {#syntax#}await{#endsyntax#} does not suspend; instead it copies the return value directly from the target function's frame.

In general, {#syntax#}suspend{#endsyntax#} is lower level than {#syntax#}await{#endsyntax#}. Most application code will use only {#syntax#}async{#endsyntax#} and {#syntax#}await{#endsyntax#}, but event loop implementations will make use of {#syntax#}suspend{#endsyntax#} internally.

Putting all of this together, here is an example of typical {#syntax#}async{#endsyntax#}/{#syntax#}await{#endsyntax#} usage:

Now we remove the {#syntax#}suspend{#endsyntax#} and {#syntax#}resume{#endsyntax#} code, and observe the same behavior, with one tiny difference:

Previously, the {#syntax#}fetchUrl{#endsyntax#} and {#syntax#}readFile{#endsyntax#} functions suspended, and were resumed in an order determined by the {#syntax#}main{#endsyntax#} function. Now, since there are no suspend points, the order of the printed "... returning" messages is determined by the order of {#syntax#}async{#endsyntax#} callsites.

Builtin functions are provided by the compiler and are prefixed with @. The {#syntax#}comptime{#endsyntax#} keyword on a parameter means that the parameter must be known at compile time.

{#syntax#}@addWithOverflow(comptime T: type, a: T, b: T, result: *T) bool{#endsyntax#}

Performs {#syntax#}result.* = a + b{#endsyntax#}. If overflow or underflow occurs, stores the overflowed bits in {#syntax#}result{#endsyntax#} and returns {#syntax#}true{#endsyntax#}. If no overflow or underflow occurs, returns {#syntax#}false{#endsyntax#}.

{#syntax#}@alignCast(comptime alignment: u29, ptr: anytype) anytype{#endsyntax#}

{#syntax#}ptr{#endsyntax#} can be {#syntax#}*T{#endsyntax#}, {#syntax#}fn(){#endsyntax#}, {#syntax#}?*T{#endsyntax#}, {#syntax#}?fn(){#endsyntax#}, or {#syntax#}[]T{#endsyntax#}. It returns the same type as {#syntax#}ptr{#endsyntax#} except with the alignment adjusted to the new value.

A {#link|pointer alignment safety check|Incorrect Pointer Alignment#} is added to the generated code to make sure the pointer is aligned as promised.

{#syntax#}@alignOf(comptime T: type) comptime_int{#endsyntax#}

This function returns the number of bytes that this type should be aligned to for the current target to match the C ABI. When the child type of a pointer has this alignment, the alignment can be omitted from the type.

{#syntax#}const assert = @import("std").debug.assert;
comptime {
    assert(*u32 == *align(@alignOf(u32)) u32);
}{#endsyntax#}

The result is a target-specific compile time constant. It is guaranteed to be less than or equal to {#link|@sizeOf(T)|@sizeOf#}.

{#syntax#}@as(comptime T: type, expression) T{#endsyntax#}

Performs {#link|Type Coercion#}. This cast is allowed when the conversion is unambiguous and safe, and is the preferred way to convert between types, whenever possible.

{#syntax#}@asyncCall(frame_buffer: []align(@alignOf(@Frame(anyAsyncFunction))) u8, result_ptr, function_ptr, args: anytype) anyframe->T{#endsyntax#}

{#syntax#}@asyncCall{#endsyntax#} performs an {#syntax#}async{#endsyntax#} call on a function pointer, which may or may not be an {#link|async function|Async Functions#}.

The provided {#syntax#}frame_buffer{#endsyntax#} must be large enough to fit the entire function frame. This size can be determined with {#link|@frameSize#}. To provide a too-small buffer invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}result_ptr{#endsyntax#} is optional ({#link|null#} may be provided). If provided, the function call will write its result directly to the result pointer, which will be available to read after {#link|await|Async and Await#} completes. Any result location provided to {#syntax#}await{#endsyntax#} will copy the result from {#syntax#}result_ptr{#endsyntax#}.

{#syntax#}@atomicLoad(comptime T: type, ptr: *const T, comptime ordering: builtin.AtomicOrder) T{#endsyntax#}

This builtin function atomically dereferences a pointer and returns the value.

{#syntax#}T{#endsyntax#} must be a pointer, a {#syntax#}bool{#endsyntax#}, a float, an integer or an enum.

{#syntax#}@atomicRmw(comptime T: type, ptr: *T, comptime op: builtin.AtomicRmwOp, operand: T, comptime ordering: builtin.AtomicOrder) T{#endsyntax#}

This builtin function atomically modifies memory and then returns the previous value.

{#syntax#}T{#endsyntax#} must be a pointer, a {#syntax#}bool{#endsyntax#}, a float, an integer or an enum.

Supported operations:

• {#syntax#}.Xchg{#endsyntax#} - stores the operand unmodified. Supports enums, integers and floats.
• {#syntax#}.Add{#endsyntax#} - for integers, twos complement wraparound addition. Also supports {#link|Floats#}.
• {#syntax#}.Sub{#endsyntax#} - for integers, twos complement wraparound subtraction. Also supports {#link|Floats#}.
• {#syntax#}.And{#endsyntax#} - bitwise and
• {#syntax#}.Nand{#endsyntax#} - bitwise nand
• {#syntax#}.Or{#endsyntax#} - bitwise or
• {#syntax#}.Xor{#endsyntax#} - bitwise xor
• {#syntax#}.Max{#endsyntax#} - stores the operand if it is larger. Supports integers and floats.
• {#syntax#}.Min{#endsyntax#} - stores the operand if it is smaller. Supports integers and floats.

{#syntax#}@atomicStore(comptime T: type, ptr: *T, value: T, comptime ordering: builtin.AtomicOrder) void{#endsyntax#}

This builtin function atomically stores a value.

{#syntax#}T{#endsyntax#} must be a pointer, a {#syntax#}bool{#endsyntax#}, a float, an integer or an enum.

{#syntax#}@bitCast(comptime DestType: type, value: anytype) DestType{#endsyntax#}

Converts a value of one type to another type.

Asserts that {#syntax#}@sizeOf(@TypeOf(value)) == @sizeOf(DestType){#endsyntax#}.

Asserts that {#syntax#}@typeInfo(DestType) != .Pointer{#endsyntax#}. Use {#syntax#}@ptrCast{#endsyntax#} or {#syntax#}@intToPtr{#endsyntax#} if you need this.

Can be used for these things for example:

• Convert {#syntax#}f32{#endsyntax#} to {#syntax#}u32{#endsyntax#} bits
• Convert {#syntax#}i32{#endsyntax#} to {#syntax#}u32{#endsyntax#} preserving twos complement

Works at compile-time if {#syntax#}value{#endsyntax#} is known at compile time. It's a compile error to bitcast a value of undefined layout; this means that, besides the restriction from types which possess dedicated casting builtins (enums, pointers, error sets), bare structs, error unions, slices, optionals, and any other type without a well-defined memory layout, also cannot be used in this operation.

{#syntax#}@bitOffsetOf(comptime T: type, comptime field_name: []const u8) comptime_int{#endsyntax#}

Returns the bit offset of a field relative to its containing struct.

For non {#link|packed structs|packed struct#}, this will always be divisible by {#syntax#}8{#endsyntax#}. For packed structs, non-byte-aligned fields will share a byte offset, but they will have different bit offsets.

{#syntax#}@boolToInt(value: bool) u1{#endsyntax#}

Converts {#syntax#}true{#endsyntax#} to {#syntax#}@as(u1, 1){#endsyntax#} and {#syntax#}false{#endsyntax#} to {#syntax#}@as(u1, 0){#endsyntax#}.

If the value is known at compile-time, the return type is {#syntax#}comptime_int{#endsyntax#} instead of {#syntax#}u1{#endsyntax#}.

{#syntax#}@bitSizeOf(comptime T: type) comptime_int{#endsyntax#}

This function returns the number of bits it takes to store {#syntax#}T{#endsyntax#} in memory if the type were a field in a packed struct/union. The result is a target-specific compile time constant.

This function measures the size at runtime. For types that are disallowed at runtime, such as {#syntax#}comptime_int{#endsyntax#} and {#syntax#}type{#endsyntax#}, the result is {#syntax#}0{#endsyntax#}.

{#syntax#}@breakpoint(){#endsyntax#}

This function inserts a platform-specific debug trap instruction which causes debuggers to break there.

This function is only valid within function scope.

{#syntax#}@mulAdd(comptime T: type, a: T, b: T, c: T) T{#endsyntax#}

Fused multiply add, similar to {#syntax#}(a * b) + c{#endsyntax#}, except only rounds once, and is thus more accurate.

Supports {#link|Floats#} and {#link|Vectors#} of floats.

{#syntax#}@byteSwap(operand: anytype) T{#endsyntax#}

{#syntax#}@TypeOf(operand){#endsyntax#} must be an integer type or an integer vector type with bit count evenly divisible by 8.

{#syntax#}operand{#endsyntax#} may be an {#link|integer|Integers#} or {#link|vector|Vectors#}.

Swaps the byte order of the integer. This converts a big endian integer to a little endian integer, and converts a little endian integer to a big endian integer.

Note that for the purposes of memory layout with respect to endianness, the integer type should be related to the number of bytes reported by {#link|@sizeOf#} bytes. This is demonstrated with {#syntax#}u24{#endsyntax#}. {#syntax#}@sizeOf(u24) == 4{#endsyntax#}, which means that a {#syntax#}u24{#endsyntax#} stored in memory takes 4 bytes, and those 4 bytes are what are swapped on a little vs big endian system. On the other hand, if {#syntax#}T{#endsyntax#} is specified to be {#syntax#}u24{#endsyntax#}, then only 3 bytes are reversed.

{#syntax#}@bitReverse(integer: anytype) T{#endsyntax#}

{#syntax#}@TypeOf(anytype){#endsyntax#} accepts any integer type or integer vector type.

Reverses the bitpattern of an integer value, including the sign bit if applicable.

For example 0b10110110 ({#syntax#}u8 = 182{#endsyntax#}, {#syntax#}i8 = -74{#endsyntax#}) becomes 0b01101101 ({#syntax#}u8 = 109{#endsyntax#}, {#syntax#}i8 = 109{#endsyntax#}).

{#syntax#}@offsetOf(comptime T: type, comptime field_name: []const u8) comptime_int{#endsyntax#}

Returns the byte offset of a field relative to its containing struct.

{#syntax#}@call(options: std.builtin.CallOptions, function: anytype, args: anytype) anytype{#endsyntax#}

Calls a function, in the same way that invoking an expression with parentheses does:

{#syntax#}@call{#endsyntax#} allows more flexibility than normal function call syntax does. The {#syntax#}CallOptions{#endsyntax#} struct is reproduced here:

{#syntax#}@cDefine(comptime name: []u8, value){#endsyntax#}

This function can only occur inside {#syntax#}@cImport{#endsyntax#}.

This appends #define $name $value to the {#syntax#}@cImport{#endsyntax#} temporary buffer.

To define without a value, like this:

#define _GNU_SOURCE

Use the void value, like this:

{#syntax#}@cDefine("_GNU_SOURCE", {}){#endsyntax#}

{#syntax#}@cImport(expression) type{#endsyntax#}

This function parses C code and imports the functions, types, variables, and compatible macro definitions into a new empty struct type, and then returns that type.

{#syntax#}expression{#endsyntax#} is interpreted at compile time. The builtin functions {#syntax#}@cInclude{#endsyntax#}, {#syntax#}@cDefine{#endsyntax#}, and {#syntax#}@cUndef{#endsyntax#} work within this expression, appending to a temporary buffer which is then parsed as C code.

Usually you should only have one {#syntax#}@cImport{#endsyntax#} in your entire application, because it saves the compiler from invoking clang multiple times, and prevents inline functions from being duplicated.

Reasons for having multiple {#syntax#}@cImport{#endsyntax#} expressions would be:

• To avoid a symbol collision, for example if foo.h and bar.h both #define CONNECTION_COUNT
• To analyze the C code with different preprocessor defines

{#syntax#}@cInclude(comptime path: []u8){#endsyntax#}

This function can only occur inside {#syntax#}@cImport{#endsyntax#}.

This appends #include <$path>\n to the {#syntax#}c_import{#endsyntax#} temporary buffer.

{#syntax#}@clz(operand: anytype){#endsyntax#}

{#syntax#}@TypeOf(operand){#endsyntax#} must be an integer type or an integer vector type.

{#syntax#}operand{#endsyntax#} may be an {#link|integer|Integers#} or {#link|vector|Vectors#}.

This function counts the number of most-significant (leading in a big-Endian sense) zeroes in an integer.

If {#syntax#}operand{#endsyntax#} is a {#link|comptime#}-known integer, the return type is {#syntax#}comptime_int{#endsyntax#}. Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number of bits that can represent the bit count of the integer type.

If {#syntax#}operand{#endsyntax#} is zero, {#syntax#}@clz{#endsyntax#} returns the bit width of integer type {#syntax#}T{#endsyntax#}.

{#syntax#}@cmpxchgStrong(comptime T: type, ptr: *T, expected_value: T, new_value: T, success_order: AtomicOrder, fail_order: AtomicOrder) ?T{#endsyntax#}

This function performs a strong atomic compare exchange operation. It's the equivalent of this code, except atomic:

If you are using cmpxchg in a loop, {#link|@cmpxchgWeak#} is the better choice, because it can be implemented more efficiently in machine instructions.

{#syntax#}T{#endsyntax#} must be a pointer, a {#syntax#}bool{#endsyntax#}, a float, an integer or an enum.

{#syntax#}@typeInfo(@TypeOf(ptr)).Pointer.alignment{#endsyntax#} must be {#syntax#}>= @sizeOf(T).{#endsyntax#}

{#syntax#}@cmpxchgWeak(comptime T: type, ptr: *T, expected_value: T, new_value: T, success_order: AtomicOrder, fail_order: AtomicOrder) ?T{#endsyntax#}

This function performs a weak atomic compare exchange operation. It's the equivalent of this code, except atomic:

If you are using cmpxchg in a loop, the sporadic failure will be no problem, and {#syntax#}cmpxchgWeak{#endsyntax#} is the better choice, because it can be implemented more efficiently in machine instructions. However if you need a stronger guarantee, use {#link|@cmpxchgStrong#}.

{#syntax#}T{#endsyntax#} must be a pointer, a {#syntax#}bool{#endsyntax#}, a float, an integer or an enum.

{#syntax#}@typeInfo(@TypeOf(ptr)).Pointer.alignment{#endsyntax#} must be {#syntax#}>= @sizeOf(T).{#endsyntax#}

{#syntax#}@compileError(comptime msg: []u8){#endsyntax#}

This function, when semantically analyzed, causes a compile error with the message {#syntax#}msg{#endsyntax#}.

There are several ways that code avoids being semantically checked, such as using {#syntax#}if{#endsyntax#} or {#syntax#}switch{#endsyntax#} with compile time constants, and {#syntax#}comptime{#endsyntax#} functions.

{#syntax#}@compileLog(args: ...){#endsyntax#}

This function prints the arguments passed to it at compile-time.

To prevent accidentally leaving compile log statements in a codebase, a compilation error is added to the build, pointing to the compile log statement. This error prevents code from being generated, but does not otherwise interfere with analysis.

This function can be used to do "printf debugging" on compile-time executing code.

will output:

If all {#syntax#}@compileLog{#endsyntax#} calls are removed or not encountered by analysis, the program compiles successfully and the generated executable prints:

{#syntax#}@ctz(operand: anytype){#endsyntax#}

{#syntax#}@TypeOf(operand){#endsyntax#} must be an integer type or an integer vector type.

{#syntax#}operand{#endsyntax#} may be an {#link|integer|Integers#} or {#link|vector|Vectors#}.

This function counts the number of least-significant (trailing in a big-Endian sense) zeroes in an integer.

If {#syntax#}operand{#endsyntax#} is a {#link|comptime#}-known integer, the return type is {#syntax#}comptime_int{#endsyntax#}. Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number of bits that can represent the bit count of the integer type.

If {#syntax#}operand{#endsyntax#} is zero, {#syntax#}@ctz{#endsyntax#} returns the bit width of integer type {#syntax#}T{#endsyntax#}.

{#syntax#}@cUndef(comptime name: []u8){#endsyntax#}

This function can only occur inside {#syntax#}@cImport{#endsyntax#}.

This appends #undef $name to the {#syntax#}@cImport{#endsyntax#} temporary buffer.

{#syntax#}@divExact(numerator: T, denominator: T) T{#endsyntax#}

Exact division. Caller guarantees {#syntax#}denominator != 0{#endsyntax#} and {#syntax#}@divTrunc(numerator, denominator) * denominator == numerator{#endsyntax#}.

• {#syntax#}@divExact(6, 3) == 2{#endsyntax#}
• {#syntax#}@divExact(a, b) * b == a{#endsyntax#}

For a function that returns a possible error code, use {#syntax#}@import("std").math.divExact{#endsyntax#}.

{#syntax#}@divFloor(numerator: T, denominator: T) T{#endsyntax#}

Floored division. Rounds toward negative infinity. For unsigned integers it is the same as {#syntax#}numerator / denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator != 0{#endsyntax#} and {#syntax#}!(@typeInfo(T) == .Int and T.is_signed and numerator == std.math.minInt(T) and denominator == -1){#endsyntax#}.

• {#syntax#}@divFloor(-5, 3) == -2{#endsyntax#}
• {#syntax#}(@divFloor(a, b) * b) + @mod(a, b) == a{#endsyntax#}

For a function that returns a possible error code, use {#syntax#}@import("std").math.divFloor{#endsyntax#}.

{#syntax#}@divTrunc(numerator: T, denominator: T) T{#endsyntax#}

Truncated division. Rounds toward zero. For unsigned integers it is the same as {#syntax#}numerator / denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator != 0{#endsyntax#} and {#syntax#}!(@typeInfo(T) == .Int and T.is_signed and numerator == std.math.minInt(T) and denominator == -1){#endsyntax#}.

• {#syntax#}@divTrunc(-5, 3) == -1{#endsyntax#}
• {#syntax#}(@divTrunc(a, b) * b) + @rem(a, b) == a{#endsyntax#}

For a function that returns a possible error code, use {#syntax#}@import("std").math.divTrunc{#endsyntax#}.

{#syntax#}@embedFile(comptime path: []const u8) *const [N:0]u8{#endsyntax#}

This function returns a compile time constant pointer to null-terminated, fixed-size array with length equal to the byte count of the file given by {#syntax#}path{#endsyntax#}. The contents of the array are the contents of the file. This is equivalent to a {#link|string literal|String Literals and Unicode Code Point Literals#} with the file contents.

{#syntax#}path{#endsyntax#} is absolute or relative to the current file, just like {#syntax#}@import{#endsyntax#}.

{#syntax#}@enumToInt(enum_or_tagged_union: anytype) anytype{#endsyntax#}

Converts an enumeration value into its integer tag type. When a tagged union is passed, the tag value is used as the enumeration value.

If there is only one possible enum value, the result is a {#syntax#}comptime_int{#endsyntax#} known at {#link|comptime#}.

{#syntax#}@errorName(err: anyerror) [:0]const u8{#endsyntax#}

This function returns the string representation of an error. The string representation of {#syntax#}error.OutOfMem{#endsyntax#} is {#syntax#}"OutOfMem"{#endsyntax#}.

If there are no calls to {#syntax#}@errorName{#endsyntax#} in an entire application, or all calls have a compile-time known value for {#syntax#}err{#endsyntax#}, then no error name table will be generated.

{#syntax#}@errorReturnTrace() ?*builtin.StackTrace{#endsyntax#}

If the binary is built with error return tracing, and this function is invoked in a function that calls a function with an error or error union return type, returns a stack trace object. Otherwise returns {#link|null#}.

{#syntax#}@errorToInt(err: anytype) std.meta.Int(.unsigned, @sizeOf(anyerror) * 8){#endsyntax#}

Supports the following types:

• {#link|The Global Error Set#}
• {#link|Error Set Type#}
• {#link|Error Union Type#}

Converts an error to the integer representation of an error.

It is generally recommended to avoid this cast, as the integer representation of an error is not stable across source code changes.

{#syntax#}@errSetCast(comptime T: DestType, value: anytype) DestType{#endsyntax#}

Converts an error value from one error set to another error set. Attempting to convert an error which is not in the destination error set results in safety-protected {#link|Undefined Behavior#}.

{#syntax#}@export(declaration, comptime options: std.builtin.ExportOptions) void{#endsyntax#}

Creates a symbol in the output object file.

declaration must be one of two things:

• An identifier ({#syntax#}x{#endsyntax#}) identifying a {#link|function|Functions#} or a {#link|variable|Container Level Variables#}.
• Field access ({#syntax#}x.y{#endsyntax#}) looking up a {#link|function|Functions#} or a {#link|variable|Container Level Variables#}.

This builtin can be called from a {#link|comptime#} block to conditionally export symbols. When declaration is a function with the C calling convention and {#syntax#}options.linkage{#endsyntax#} is {#syntax#}Strong{#endsyntax#}, this is equivalent to the {#syntax#}export{#endsyntax#} keyword used on a function:

This is equivalent to:

Note that even when using {#syntax#}export{#endsyntax#}, the {#syntax#}@"foo"{#endsyntax#} syntax for {#link|identifiers|Identifiers#} can be used to choose any string for the symbol name:

When looking at the resulting object, you can see the symbol is used verbatim:

00000000000001f0 T A function name that is a complete sentence.

{#syntax#}@extern(T: type, comptime options: std.builtin.ExternOptions) *T{#endsyntax#}

Creates a reference to an external symbol in the output object file.

{#syntax#}@fence(order: AtomicOrder){#endsyntax#}

The {#syntax#}fence{#endsyntax#} function is used to introduce happens-before edges between operations.

{#syntax#}AtomicOrder{#endsyntax#} can be found with {#syntax#}@import("std").builtin.AtomicOrder{#endsyntax#}.

{#syntax#}@field(lhs: anytype, comptime field_name: []const u8) (field){#endsyntax#}

Performs field access by a compile-time string. Works on both fields and declarations.

{#syntax#}@fieldParentPtr(comptime ParentType: type, comptime field_name: []const u8,
    field_ptr: *T) *ParentType{#endsyntax#}

Given a pointer to a field, returns the base pointer of a struct.

{#syntax#}@floatCast(comptime DestType: type, value: anytype) DestType{#endsyntax#}

Convert from one float type to another. This cast is safe, but may cause the numeric value to lose precision.

{#syntax#}@floatToInt(comptime DestType: type, float: anytype) DestType{#endsyntax#}

Converts the integer part of a floating point number to the destination type.

If the integer part of the floating point number cannot fit in the destination type, it invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}@frame() *@Frame(func){#endsyntax#}

This function returns a pointer to the frame for a given function. This type can be {#link|coerced|Type Coercion#} to {#syntax#}anyframe->T{#endsyntax#} and to {#syntax#}anyframe{#endsyntax#}, where {#syntax#}T{#endsyntax#} is the return type of the function in scope.

This function does not mark a suspension point, but it does cause the function in scope to become an {#link|async function|Async Functions#}.

{#syntax#}@Frame(func: anytype) type{#endsyntax#}

This function returns the frame type of a function. This works for {#link|Async Functions#} as well as any function without a specific calling convention.

This type is suitable to be used as the return type of {#link|async|Async and Await#} which allows one to, for example, heap-allocate an async function frame:

{#syntax#}@frameAddress() usize{#endsyntax#}

This function returns the base pointer of the current stack frame.

The implications of this are target specific and not consistent across all platforms. The frame address may not be available in release mode due to aggressive optimizations.

This function is only valid within function scope.

{#syntax#}@frameSize(func: anytype) usize{#endsyntax#}

This is the same as {#syntax#}@sizeOf(@Frame(func)){#endsyntax#}, where {#syntax#}func{#endsyntax#} may be runtime-known.

This function is typically used in conjunction with {#link|@asyncCall#}.

{#syntax#}@hasDecl(comptime Container: type, comptime name: []const u8) bool{#endsyntax#}

Returns whether or not a {#link|struct#}, {#link|enum#}, or {#link|union#} has a declaration matching {#syntax#}name{#endsyntax#}.

{#syntax#}@hasField(comptime Container: type, comptime name: []const u8) bool{#endsyntax#}

Returns whether the field name of a struct, union, or enum exists.

The result is a compile time constant.

It does not include functions, variables, or constants.

{#syntax#}@import(comptime path: []u8) type{#endsyntax#}

This function finds a zig file corresponding to {#syntax#}path{#endsyntax#} and adds it to the build, if it is not already added.

Zig source files are implicitly structs, with a name equal to the file's basename with the extension truncated. {#syntax#}@import{#endsyntax#} returns the struct type corresponding to the file.

Declarations which have the {#syntax#}pub{#endsyntax#} keyword may be referenced from a different source file than the one they are declared in.

{#syntax#}path{#endsyntax#} can be a relative path or it can be the name of a package. If it is a relative path, it is relative to the file that contains the {#syntax#}@import{#endsyntax#} function call.

The following packages are always available:

• {#syntax#}@import("std"){#endsyntax#} - Zig Standard Library
• {#syntax#}@import("builtin"){#endsyntax#} - Target-specific information The command zig build-exe --show-builtin outputs the source to stdout for reference.
• {#syntax#}@import("root"){#endsyntax#} - Points to the root source file This is usually `src/main.zig` but it depends on what file is chosen to be built.

{#syntax#}@intCast(comptime DestType: type, int: anytype) DestType{#endsyntax#}

Converts an integer to another integer while keeping the same numerical value. Attempting to convert a number which is out of range of the destination type results in safety-protected {#link|Undefined Behavior#}.

To truncate the significant bits of a number out of range of the destination type, use {#link|@truncate#}.

If {#syntax#}T{#endsyntax#} is {#syntax#}comptime_int{#endsyntax#}, then this is semantically equivalent to {#link|Type Coercion#}.

{#syntax#}@intToEnum(comptime DestType: type, integer: anytype) DestType{#endsyntax#}

Converts an integer into an {#link|enum#} value.

Attempting to convert an integer which represents no value in the chosen enum type invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}@intToError(value: std.meta.Int(.unsigned, @sizeOf(anyerror) * 8)) anyerror{#endsyntax#}

Converts from the integer representation of an error into {#link|The Global Error Set#} type.

It is generally recommended to avoid this cast, as the integer representation of an error is not stable across source code changes.

Attempting to convert an integer that does not correspond to any error results in safety-protected {#link|Undefined Behavior#}.

{#syntax#}@intToFloat(comptime DestType: type, int: anytype) DestType{#endsyntax#}

Converts an integer to the closest floating point representation. To convert the other way, use {#link|@floatToInt#}. This cast is always safe.

{#syntax#}@intToPtr(comptime DestType: type, address: usize) DestType{#endsyntax#}

Converts an integer to a {#link|pointer|Pointers#}. To convert the other way, use {#link|@ptrToInt#}. Casting an address of 0 to a destination type which in not {#link|optional|Optional Pointers#} and does not have the {#syntax#}allowzero{#endsyntax#} attribute will result in a {#link|Pointer Cast Invalid Null#} panic when runtime safety checks are enabled.

If the destination pointer type does not allow address zero and {#syntax#}address{#endsyntax#} is zero, this invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}@maximum(a: T, b: T) T{#endsyntax#}

Returns the maximum value of {#syntax#}a{#endsyntax#} and {#syntax#}b{#endsyntax#}. This builtin accepts integers, floats, and vectors of either. In the latter case, the operation is performed element wise.

NaNs are handled as follows: if one of the operands of a (pairwise) operation is NaN, the other operand is returned. If both operands are NaN, NaN is returned.

{#syntax#}@memcpy(noalias dest: [*]u8, noalias source: [*]const u8, byte_count: usize){#endsyntax#}

This function copies bytes from one region of memory to another. {#syntax#}dest{#endsyntax#} and {#syntax#}source{#endsyntax#} are both pointers and must not overlap.

This function is a low level intrinsic with no safety mechanisms. Most code should not use this function, instead using something like this:

{#syntax#}for (source[0..byte_count]) |b, i| dest[i] = b;{#endsyntax#}

The optimizer is intelligent enough to turn the above snippet into a memcpy.

There is also a standard library function for this:

{#syntax#}const mem = @import("std").mem;
mem.copy(u8, dest[0..byte_count], source[0..byte_count]);{#endsyntax#}

{#syntax#}@memset(dest: [*]u8, c: u8, byte_count: usize){#endsyntax#}

This function sets a region of memory to {#syntax#}c{#endsyntax#}. {#syntax#}dest{#endsyntax#} is a pointer.

This function is a low level intrinsic with no safety mechanisms. Most code should not use this function, instead using something like this:

{#syntax#}for (dest[0..byte_count]) |*b| b.* = c;{#endsyntax#}

The optimizer is intelligent enough to turn the above snippet into a memset.

There is also a standard library function for this:

{#syntax#}const mem = @import("std").mem;
mem.set(u8, dest, c);{#endsyntax#}

{#syntax#}@minimum(a: T, b: T) T{#endsyntax#}

Returns the minimum value of {#syntax#}a{#endsyntax#} and {#syntax#}b{#endsyntax#}. This builtin accepts integers, floats, and vectors of either. In the latter case, the operation is performed element wise.

NaNs are handled as follows: if one of the operands of a (pairwise) operation is NaN, the other operand is returned. If both operands are NaN, NaN is returned.

{#syntax#}@wasmMemorySize(index: u32) u32{#endsyntax#}

This function returns the size of the Wasm memory identified by {#syntax#}index{#endsyntax#} as an unsigned value in units of Wasm pages. Note that each Wasm page is 64KB in size.

This function is a low level intrinsic with no safety mechanisms usually useful for allocator designers targeting Wasm. So unless you are writing a new allocator from scratch, you should use something like {#syntax#}@import("std").heap.WasmPageAllocator{#endsyntax#}.

{#syntax#}@wasmMemoryGrow(index: u32, delta: u32) i32{#endsyntax#}

This function increases the size of the Wasm memory identified by {#syntax#}index{#endsyntax#} by {#syntax#}delta{#endsyntax#} in units of unsigned number of Wasm pages. Note that each Wasm page is 64KB in size. On success, returns previous memory size; on failure, if the allocation fails, returns -1.

This function is a low level intrinsic with no safety mechanisms usually useful for allocator designers targeting Wasm. So unless you are writing a new allocator from scratch, you should use something like {#syntax#}@import("std").heap.WasmPageAllocator{#endsyntax#}.

{#syntax#}@mod(numerator: T, denominator: T) T{#endsyntax#}

Modulus division. For unsigned integers this is the same as {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}, otherwise the operation will result in a {#link|Remainder Division by Zero#} when runtime safety checks are enabled.

• {#syntax#}@mod(-5, 3) == 1{#endsyntax#}
• {#syntax#}(@divFloor(a, b) * b) + @mod(a, b) == a{#endsyntax#}

For a function that returns an error code, see {#syntax#}@import("std").math.mod{#endsyntax#}.

{#syntax#}@mulWithOverflow(comptime T: type, a: T, b: T, result: *T) bool{#endsyntax#}

Performs {#syntax#}result.* = a * b{#endsyntax#}. If overflow or underflow occurs, stores the overflowed bits in {#syntax#}result{#endsyntax#} and returns {#syntax#}true{#endsyntax#}. If no overflow or underflow occurs, returns {#syntax#}false{#endsyntax#}.

{#syntax#}@panic(message: []const u8) noreturn{#endsyntax#}

Invokes the panic handler function. By default the panic handler function calls the public {#syntax#}panic{#endsyntax#} function exposed in the root source file, or if there is not one specified, the {#syntax#}std.builtin.default_panic{#endsyntax#} function from {#syntax#}std/builtin.zig{#endsyntax#}.

Generally it is better to use {#syntax#}@import("std").debug.panic{#endsyntax#}. However, {#syntax#}@panic{#endsyntax#} can be useful for 2 scenarios:

• From library code, calling the programmer's panic function if they exposed one in the root source file.
• When mixing C and Zig code, calling the canonical panic implementation across multiple .o files.

{#syntax#}@popCount(operand: anytype){#endsyntax#}

{#syntax#}@TypeOf(operand){#endsyntax#} must be an integer type.

{#syntax#}operand{#endsyntax#} may be an {#link|integer|Integers#} or {#link|vector|Vectors#}.

Counts the number of bits set in an integer.

If {#syntax#}operand{#endsyntax#} is a {#link|comptime#}-known integer, the return type is {#syntax#}comptime_int{#endsyntax#}. Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number of bits that can represent the bit count of the integer type.

{#syntax#}@prefetch(ptr: anytype, comptime options: std.builtin.PrefetchOptions){#endsyntax#}

This builtin tells the compiler to emit a prefetch instruction if supported by the target CPU. If the target CPU does not support the requested prefetch instruction, this builtin is a noop. This function has no effect on the behavior of the program, only on the performance characteristics.

The {#syntax#}ptr{#endsyntax#} argument may be any pointer type and determines the memory address to prefetch. This function does not dereference the pointer, it is perfectly legal to pass a pointer to invalid memory to this function and no illegal behavior will result.

The {#syntax#}options{#endsyntax#} argument is the following struct:

{#syntax#}@ptrCast(comptime DestType: type, value: anytype) DestType{#endsyntax#}

Converts a pointer of one type to a pointer of another type.

{#link|Optional Pointers#} are allowed. Casting an optional pointer which is {#link|null#} to a non-optional pointer invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}@ptrToInt(value: anytype) usize{#endsyntax#}

Converts {#syntax#}value{#endsyntax#} to a {#syntax#}usize{#endsyntax#} which is the address of the pointer. {#syntax#}value{#endsyntax#} can be one of these types:

• {#syntax#}*T{#endsyntax#}
• {#syntax#}?*T{#endsyntax#}
• {#syntax#}fn(){#endsyntax#}
• {#syntax#}?fn(){#endsyntax#}

To convert the other way, use {#link|@intToPtr#}

{#syntax#}@rem(numerator: T, denominator: T) T{#endsyntax#}

Remainder division. For unsigned integers this is the same as {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}, otherwise the operation will result in a {#link|Remainder Division by Zero#} when runtime safety checks are enabled.

• {#syntax#}@rem(-5, 3) == -2{#endsyntax#}
• {#syntax#}(@divTrunc(a, b) * b) + @rem(a, b) == a{#endsyntax#}

For a function that returns an error code, see {#syntax#}@import("std").math.rem{#endsyntax#}.

{#syntax#}@returnAddress() usize{#endsyntax#}

This function returns the address of the next machine code instruction that will be executed when the current function returns.

The implications of this are target specific and not consistent across all platforms.

This function is only valid within function scope. If the function gets inlined into a calling function, the returned address will apply to the calling function.

{#syntax#}@select(comptime T: type, pred: @Vector(len, bool), a: @Vector(len, T), b: @Vector(len, T)) @Vector(len, T){#endsyntax#}

Selects values element-wise from {#syntax#}a{#endsyntax#} or {#syntax#}b{#endsyntax#} based on {#syntax#}pred{#endsyntax#}. If {#syntax#}pred[i]{#endsyntax#} is {#syntax#}true{#endsyntax#}, the corresponding element in the result will be {#syntax#}a[i]{#endsyntax#} and otherwise {#syntax#}b[i]{#endsyntax#}.

{#syntax#}@setAlignStack(comptime alignment: u29){#endsyntax#}

Ensures that a function will have a stack alignment of at least {#syntax#}alignment{#endsyntax#} bytes.

{#syntax#}@setCold(comptime is_cold: bool){#endsyntax#}

Tells the optimizer that a function is rarely called.

{#syntax#}@setEvalBranchQuota(comptime new_quota: u32){#endsyntax#}

Changes the maximum number of backwards branches that compile-time code execution can use before giving up and making a compile error.

If the {#syntax#}new_quota{#endsyntax#} is smaller than the default quota ({#syntax#}1000{#endsyntax#}) or a previously explicitly set quota, it is ignored.

Example:

Now we use {#syntax#}@setEvalBranchQuota{#endsyntax#}:

{#syntax#}@setFloatMode(comptime mode: @import("std").builtin.FloatMode){#endsyntax#}

Sets the floating point mode of the current scope. Possible values are:

• {#syntax#}Strict{#endsyntax#} (default) - Floating point operations follow strict IEEE compliance.
• {#syntax#}Optimized{#endsyntax#} - Floating point operations may do all of the following:
  • Assume the arguments and result are not NaN. Optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined.
  • Assume the arguments and result are not +/-Inf. Optimizations are required to retain defined behavior over +/-Inf, but the value of the result is undefined.
  • Treat the sign of a zero argument or result as insignificant.
  • Use the reciprocal of an argument rather than perform division.
  • Perform floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-and-add).
  • Perform algebraically equivalent transformations that may change results in floating point (e.g. reassociate).
  This is equivalent to -ffast-math in GCC.

The floating point mode is inherited by child scopes, and can be overridden in any scope. You can set the floating point mode in a struct or module scope by using a comptime block.

{#syntax#}@setRuntimeSafety(comptime safety_on: bool) void{#endsyntax#}

Sets whether runtime safety checks are enabled for the scope that contains the function call.

Note: it is planned to replace {#syntax#}@setRuntimeSafety{#endsyntax#} with @optimizeFor

{#syntax#}@shlExact(value: T, shift_amt: Log2T) T{#endsyntax#}

Performs the left shift operation ({#syntax#}<<{#endsyntax#}). For unsigned integers, the result is {#link|undefined#} if any 1 bits are shifted out. For signed integers, the result is {#link|undefined#} if any bits that disagree with the resultant sign bit are shifted out.

The type of {#syntax#}shift_amt{#endsyntax#} is an unsigned integer with {#syntax#}log2(@typeInfo(T).Int.bits){#endsyntax#} bits. This is because {#syntax#}shift_amt >= @typeInfo(T).Int.bits{#endsyntax#} is undefined behavior.

{#syntax#}@shlWithOverflow(comptime T: type, a: T, shift_amt: Log2T, result: *T) bool{#endsyntax#}

Performs {#syntax#}result.* = a << b{#endsyntax#}. If overflow or underflow occurs, stores the overflowed bits in {#syntax#}result{#endsyntax#} and returns {#syntax#}true{#endsyntax#}. If no overflow or underflow occurs, returns {#syntax#}false{#endsyntax#}.

The type of {#syntax#}shift_amt{#endsyntax#} is an unsigned integer with {#syntax#}log2(@typeInfo(T).Int.bits){#endsyntax#} bits. This is because {#syntax#}shift_amt >= @typeInfo(T).Int.bits{#endsyntax#} is undefined behavior.

{#syntax#}@shrExact(value: T, shift_amt: Log2T) T{#endsyntax#}

Performs the right shift operation ({#syntax#}>>{#endsyntax#}). Caller guarantees that the shift will not shift any 1 bits out.

The type of {#syntax#}shift_amt{#endsyntax#} is an unsigned integer with {#syntax#}log2(@typeInfo(T).Int.bits){#endsyntax#} bits. This is because {#syntax#}shift_amt >= @typeInfo(T).Int.bits{#endsyntax#} is undefined behavior.

{#syntax#}@shuffle(comptime E: type, a: @Vector(a_len, E), b: @Vector(b_len, E), comptime mask: @Vector(mask_len, i32)) @Vector(mask_len, E){#endsyntax#}

Constructs a new {#link|vector|Vectors#} by selecting elements from {#syntax#}a{#endsyntax#} and {#syntax#}b{#endsyntax#} based on {#syntax#}mask{#endsyntax#}.

Each element in {#syntax#}mask{#endsyntax#} selects an element from either {#syntax#}a{#endsyntax#} or {#syntax#}b{#endsyntax#}. Positive numbers select from {#syntax#}a{#endsyntax#} starting at 0. Negative values select from {#syntax#}b{#endsyntax#}, starting at {#syntax#}-1{#endsyntax#} and going down. It is recommended to use the {#syntax#}~{#endsyntax#} operator from indexes from {#syntax#}b{#endsyntax#} so that both indexes can start from {#syntax#}0{#endsyntax#} (i.e. {#syntax#}~@as(i32, 0){#endsyntax#} is {#syntax#}-1{#endsyntax#}).

For each element of {#syntax#}mask{#endsyntax#}, if it or the selected value from {#syntax#}a{#endsyntax#} or {#syntax#}b{#endsyntax#} is {#syntax#}undefined{#endsyntax#}, then the resulting element is {#syntax#}undefined{#endsyntax#}.

{#syntax#}a_len{#endsyntax#} and {#syntax#}b_len{#endsyntax#} may differ in length. Out-of-bounds element indexes in {#syntax#}mask{#endsyntax#} result in compile errors.

If {#syntax#}a{#endsyntax#} or {#syntax#}b{#endsyntax#} is {#syntax#}undefined{#endsyntax#}, it is equivalent to a vector of all {#syntax#}undefined{#endsyntax#} with the same length as the other vector. If both vectors are {#syntax#}undefined{#endsyntax#}, {#syntax#}@shuffle{#endsyntax#} returns a vector with all elements {#syntax#}undefined{#endsyntax#}.

{#syntax#}E{#endsyntax#} must be an {#link|integer|Integers#}, {#link|float|Floats#}, {#link|pointer|Pointers#}, or {#syntax#}bool{#endsyntax#}. The mask may be any vector length, and its length determines the result length.

{#syntax#}@sizeOf(comptime T: type) comptime_int{#endsyntax#}

This function returns the number of bytes it takes to store {#syntax#}T{#endsyntax#} in memory. The result is a target-specific compile time constant.

This size may contain padding bytes. If there were two consecutive T in memory, this would be the offset in bytes between element at index 0 and the element at index 1. For {#link|integer|Integers#}, consider whether you want to use {#syntax#}@sizeOf(T){#endsyntax#} or {#syntax#}@typeInfo(T).Int.bits{#endsyntax#}.

This function measures the size at runtime. For types that are disallowed at runtime, such as {#syntax#}comptime_int{#endsyntax#} and {#syntax#}type{#endsyntax#}, the result is {#syntax#}0{#endsyntax#}.

{#syntax#}@splat(comptime len: u32, scalar: anytype) @Vector(len, @TypeOf(scalar)){#endsyntax#}

Produces a vector of length {#syntax#}len{#endsyntax#} where each element is the value {#syntax#}scalar{#endsyntax#}:

{#syntax#}scalar{#endsyntax#} must be an {#link|integer|Integers#}, {#link|bool|Primitive Types#}, {#link|float|Floats#}, or {#link|pointer|Pointers#}.

{#syntax#}@reduce(comptime op: std.builtin.ReduceOp, value: anytype) E{#endsyntax#}

Transforms a {#link|vector|Vectors#} into a scalar value (of type E) by performing a sequential horizontal reduction of its elements using the specified operator {#syntax#}op{#endsyntax#}.

Not every operator is available for every vector element type:

• Every operator is available for {#link|integer|Integers#} vectors.
• {#syntax#}.And{#endsyntax#}, {#syntax#}.Or{#endsyntax#}, {#syntax#}.Xor{#endsyntax#} are additionally available for {#syntax#}bool{#endsyntax#} vectors,
• {#syntax#}.Min{#endsyntax#}, {#syntax#}.Max{#endsyntax#}, {#syntax#}.Add{#endsyntax#}, {#syntax#}.Mul{#endsyntax#} are additionally available for {#link|floating point|Floats#} vectors,

Note that {#syntax#}.Add{#endsyntax#} and {#syntax#}.Mul{#endsyntax#} reductions on integral types are wrapping; when applied on floating point types the operation associativity is preserved, unless the float mode is set to {#syntax#}Optimized{#endsyntax#}.

{#syntax#}@src() std.builtin.SourceLocation{#endsyntax#}

Returns a {#syntax#}SourceLocation{#endsyntax#} struct representing the function's name and location in the source code. This must be called in a function.

{#syntax#}@sqrt(value: anytype) @TypeOf(value){#endsyntax#}

Performs the square root of a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@sin(value: anytype) @TypeOf(value){#endsyntax#}

Sine trigonometric function on a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@cos(value: anytype) @TypeOf(value){#endsyntax#}

Cosine trigonometric function on a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@tan(value: anytype) @TypeOf(value){#endsyntax#}

Tangent trigonometric function on a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@exp(value: anytype) @TypeOf(value){#endsyntax#}

Base-e exponential function on a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@exp2(value: anytype) @TypeOf(value){#endsyntax#}

Base-2 exponential function on a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@log(value: anytype) @TypeOf(value){#endsyntax#}

Returns the natural logarithm of a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@log2(value: anytype) @TypeOf(value){#endsyntax#}

Returns the logarithm to the base 2 of a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@log10(value: anytype) @TypeOf(value){#endsyntax#}

Returns the logarithm to the base 10 of a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@fabs(value: anytype) @TypeOf(value){#endsyntax#}

Returns the absolute value of a floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@floor(value: anytype) @TypeOf(value){#endsyntax#}

Returns the largest integral value not greater than the given floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@ceil(value: anytype) @TypeOf(value){#endsyntax#}

Returns the smallest integral value not less than the given floating point number. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@trunc(value: anytype) @TypeOf(value){#endsyntax#}

Rounds the given floating point number to an integer, towards zero. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@round(value: anytype) @TypeOf(value){#endsyntax#}

Rounds the given floating point number to an integer, away from zero. Uses a dedicated hardware instruction when available.

Supports {#link|Floats#} and {#link|Vectors#} of floats, with the caveat that some float operations are not yet implemented for all float types.

{#syntax#}@subWithOverflow(comptime T: type, a: T, b: T, result: *T) bool{#endsyntax#}

Performs {#syntax#}result.* = a - b{#endsyntax#}. If overflow or underflow occurs, stores the overflowed bits in {#syntax#}result{#endsyntax#} and returns {#syntax#}true{#endsyntax#}. If no overflow or underflow occurs, returns {#syntax#}false{#endsyntax#}.

{#syntax#}@tagName(value: anytype) [:0]const u8{#endsyntax#}

Converts an enum value or union value to a string literal representing the name.

If the enum is non-exhaustive and the tag value does not map to a name, it invokes safety-checked {#link|Undefined Behavior#}.

{#syntax#}@This() type{#endsyntax#}

Returns the innermost struct, enum, or union that this function call is inside. This can be useful for an anonymous struct that needs to refer to itself:

When {#syntax#}@This(){#endsyntax#} is used at file scope, it returns a reference to the struct that corresponds to the current file.

{#syntax#}@truncate(comptime T: type, integer: anytype) T{#endsyntax#}

This function truncates bits from an integer type, resulting in a smaller or same-sized integer type.

This function always truncates the significant bits of the integer, regardless of endianness on the target platform.

Calling {#syntax#}@truncate{#endsyntax#} on a number out of range of the destination type is well defined and working code:

Use {#link|@intCast#} to convert numbers guaranteed to fit the destination type.

{#syntax#}@Type(comptime info: std.builtin.Type) type{#endsyntax#}

This function is the inverse of {#link|@typeInfo#}. It reifies type information into a {#syntax#}type{#endsyntax#}.

It is available for the following types:

• {#syntax#}type{#endsyntax#}
• {#syntax#}noreturn{#endsyntax#}
• {#syntax#}void{#endsyntax#}
• {#syntax#}bool{#endsyntax#}
• {#link|Integers#} - The maximum bit count for an integer type is {#syntax#}65535{#endsyntax#}.
• {#link|Floats#}
• {#link|Pointers#}
• {#syntax#}comptime_int{#endsyntax#}
• {#syntax#}comptime_float{#endsyntax#}
• {#syntax#}@TypeOf(undefined){#endsyntax#}
• {#syntax#}@TypeOf(null){#endsyntax#}
• {#link|Arrays#}
• {#link|Optionals#}
• {#link|Error Set Type#}
• {#link|Error Union Type#}
• {#link|Vectors#}
• {#link|opaque#}
• {#link|@Frame#}
• {#syntax#}anyframe{#endsyntax#}
• {#link|struct#}
• {#link|enum#}
• {#link|Enum Literals#}
• {#link|union#}

For these types, {#syntax#}@Type{#endsyntax#} is not available:

• {#link|Functions#}
• BoundFn

{#syntax#}@typeInfo(comptime T: type) std.builtin.Type{#endsyntax#}

Provides type reflection.

Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and {#link|error sets|Error Set Type#} has fields which are are guaranteed to be in the same order as appearance in the source file.

Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and {#link|opaques|opaque#} has declarations, which are also guaranteed to be in the same order as appearance in the source file.

{#syntax#}@typeName(T: type) *const [N:0]u8{#endsyntax#}

This function returns the string representation of a type, as an array. It is equivalent to a string literal of the type name. The returned type name is fully qualified with the parent namespace included as part of the type name with a series of dots.

{#syntax#}@TypeOf(...) type{#endsyntax#}

{#syntax#}@TypeOf{#endsyntax#} is a special builtin function that takes any (nonzero) number of expressions as parameters and returns the type of the result, using {#link|Peer Type Resolution#}.

The expressions are evaluated, however they are guaranteed to have no runtime side-effects:

{#syntax#}@unionInit(comptime Union: type, comptime active_field_name: []const u8, init_expr) Union{#endsyntax#}

This is the same thing as {#link|union#} initialization syntax, except that the field name is a {#link|comptime#}-known value rather than an identifier token.

{#syntax#}@unionInit{#endsyntax#} forwards its {#link|result location|Result Location Semantics#} to {#syntax#}init_expr{#endsyntax#}.

{#syntax#}@Vector(len: comptime_int, Element: type) type{#endsyntax#}

Creates {#link|Vectors#}.

Zig has four build modes:

• {#link|Debug#} (default)
• {#link|ReleaseFast#}
• {#link|ReleaseSafe#}
• {#link|ReleaseSmall#}

To add standard build options to a build.zig file:

This causes these options to be available:

-Drelease-safe=[bool]

Optimizations on and safety on

-Drelease-fast=[bool]

Optimizations on and safety off

-Drelease-small=[bool]

Size optimizations on and safety off

• Fast compilation speed
• Safety checks enabled
• Slow runtime performance
• Large binary size
• No reproducible build requirement

• Fast runtime performance
• Safety checks disabled
• Slow compilation speed
• Large binary size
• Reproducible build

• Medium runtime performance
• Safety checks enabled
• Slow compilation speed
• Large binary size
• Reproducible build

• Medium runtime performance
• Safety checks disabled
• Slow compilation speed
• Small binary size
• Reproducible build

Zig has a compile option --single-threaded which has the following effects:

• All {#link|Thread Local Variables#} are treated as regular {#link|Container Level Variables#}.
• The overhead of {#link|Async Functions#} becomes equivalent to function call overhead.
• The {#syntax#}@import("builtin").single_threaded{#endsyntax#} becomes {#syntax#}true{#endsyntax#} and therefore various userland APIs which read this variable become more efficient. For example {#syntax#}std.Mutex{#endsyntax#} becomes an empty data structure and all of its functions become no-ops.

Zig has many instances of undefined behavior. If undefined behavior is detected at compile-time, Zig emits a compile error and refuses to continue. Most undefined behavior that cannot be detected at compile-time can be detected at runtime. In these cases, Zig has safety checks. Safety checks can be disabled on a per-block basis with {#link|@setRuntimeSafety#}. The {#link|ReleaseFast#} and {#link|ReleaseSmall#} build modes disable all safety checks (except where overridden by {#link|@setRuntimeSafety#}) in order to facilitate optimizations.

When a safety check fails, Zig crashes with a stack trace, like this:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

To obtain the maximum value of an unsigned integer, use {#syntax#}std.math.maxInt{#endsyntax#}.

At compile-time:

At runtime:

To truncate bits, use {#link|@truncate#}.

The following operators can cause integer overflow:

• {#syntax#}+{#endsyntax#} (addition)
• {#syntax#}-{#endsyntax#} (subtraction)
• {#syntax#}-{#endsyntax#} (negation)
• {#syntax#}*{#endsyntax#} (multiplication)
• {#syntax#}/{#endsyntax#} (division)
• {#link|@divTrunc#} (division)
• {#link|@divFloor#} (division)
• {#link|@divExact#} (division)

Example with addition at compile-time:

At runtime:

These functions provided by the standard library return possible errors.

• {#syntax#}@import("std").math.add{#endsyntax#}
• {#syntax#}@import("std").math.sub{#endsyntax#}
• {#syntax#}@import("std").math.mul{#endsyntax#}
• {#syntax#}@import("std").math.divTrunc{#endsyntax#}
• {#syntax#}@import("std").math.divFloor{#endsyntax#}
• {#syntax#}@import("std").math.divExact{#endsyntax#}
• {#syntax#}@import("std").math.shl{#endsyntax#}

Example of catching an overflow for addition:

These builtins return a {#syntax#}bool{#endsyntax#} of whether or not overflow occurred, as well as returning the overflowed bits:

• {#link|@addWithOverflow#}
• {#link|@subWithOverflow#}
• {#link|@mulWithOverflow#}
• {#link|@shlWithOverflow#}

Example of {#link|@addWithOverflow#}:

These operations have guaranteed wraparound semantics.

• {#syntax#}+%{#endsyntax#} (wraparound addition)
• {#syntax#}-%{#endsyntax#} (wraparound subtraction)
• {#syntax#}-%{#endsyntax#} (wraparound negation)
• {#syntax#}*%{#endsyntax#} (wraparound multiplication)

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

One way to avoid this crash is to test for null instead of assuming non-null, with the {#syntax#}if{#endsyntax#} expression:

At compile-time:

At runtime:

One way to avoid this crash is to test for an error instead of assuming a successful result, with the {#syntax#}if{#endsyntax#} expression:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

At compile-time:

At runtime:

This safety is not available for {#syntax#}extern{#endsyntax#} or {#syntax#}packed{#endsyntax#} unions.

To change the active field of a union, assign the entire union, like this:

To change the active field of a union when a meaningful value for the field is not known, use {#link|undefined#}, like this:

TODO

This happens when casting a pointer with the address 0 to a pointer which may not have the address 0. For example, {#link|C Pointers#}, {#link|Optional Pointers#}, and {#link|allowzero#} pointers allow address zero, but normal {#link|Pointers#} do not.

At compile-time:

At runtime:

The Zig language performs no memory management on behalf of the programmer. This is why Zig has no runtime, and why Zig code works seamlessly in so many environments, including real-time software, operating system kernels, embedded devices, and low latency servers. As a consequence, Zig programmers must always be able to answer the question:

{#link|Where are the bytes?#}

Like Zig, the C programming language has manual memory management. However, unlike Zig, C has a default allocator - malloc, realloc, and free. When linking against libc, Zig exposes this allocator with {#syntax#}std.heap.c_allocator{#endsyntax#}. However, by convention, there is no default allocator in Zig. Instead, functions which need to allocate accept an {#syntax#}Allocator{#endsyntax#} parameter. Likewise, data structures such as {#syntax#}std.ArrayList{#endsyntax#} accept an {#syntax#}Allocator{#endsyntax#} parameter in their initialization functions:

In the above example, 100 bytes of stack memory are used to initialize a {#syntax#}FixedBufferAllocator{#endsyntax#}, which is then passed to a function. As a convenience there is a global {#syntax#}FixedBufferAllocator{#endsyntax#} available for quick tests at {#syntax#}std.testing.allocator{#endsyntax#}, which will also do perform basic leak detection.

Zig has a general purpose allocator available to be imported with {#syntax#}std.heap.GeneralPurposeAllocator{#endsyntax#}. However, it is still recommended to follow the {#link|Choosing an Allocator#} guide.

What allocator to use depends on a number of factors. Here is a flow chart to help you decide:

1. Are you making a library? In this case, best to accept an {#syntax#}Allocator{#endsyntax#} as a parameter and allow your library's users to decide what allocator to use.
2. Are you linking libc? In this case, {#syntax#}std.heap.c_allocator{#endsyntax#} is likely the right choice, at least for your main allocator.
3. Is the maximum number of bytes that you will need bounded by a number known at {#link|comptime#}? In this case, use {#syntax#}std.heap.FixedBufferAllocator{#endsyntax#} or {#syntax#}std.heap.ThreadSafeFixedBufferAllocator{#endsyntax#} depending on whether you need thread-safety or not.
4. Is your program a command line application which runs from start to end without any fundamental cyclical pattern (such as a video game main loop, or a web server request handler), such that it would make sense to free everything at once at the end? In this case, it is recommended to follow this pattern: {#code_begin|exe|cli_allocation#} const std = @import("std"); pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const ptr = try allocator.create(i32); std.debug.print("ptr={*}\n", .{ptr}); } {#code_end#} When using this kind of allocator, there is no need to free anything manually. Everything gets freed at once with the call to {#syntax#}arena.deinit(){#endsyntax#}.
5. Are the allocations part of a cyclical pattern such as a video game main loop, or a web server request handler? If the allocations can all be freed at once, at the end of the cycle, for example once the video game frame has been fully rendered, or the web server request has been served, then {#syntax#}std.heap.ArenaAllocator{#endsyntax#} is a great candidate. As demonstrated in the previous bullet point, this allows you to free entire arenas at once. Note also that if an upper bound of memory can be established, then {#syntax#}std.heap.FixedBufferAllocator{#endsyntax#} can be used as a further optimization.
6. Are you writing a test, and you want to make sure {#syntax#}error.OutOfMemory{#endsyntax#} is handled correctly? In this case, use {#syntax#}std.testing.FailingAllocator{#endsyntax#}.
7. Are you writing a test? In this case, use {#syntax#}std.testing.allocator{#endsyntax#}.
8. Finally, if none of the above apply, you need a general purpose allocator. Zig's general purpose allocator is available as a function that takes a {#link|comptime#} {#link|struct#} of configuration options and returns a type. Generally, you will set up one {#syntax#}std.heap.GeneralPurposeAllocator{#endsyntax#} in your main function, and then pass it or sub-allocators around to various parts of your application.
9. You can also consider {#link|Implementing an Allocator#}.

String literals such as {#syntax#}"foo"{#endsyntax#} are in the global constant data section. This is why it is an error to pass a string literal to a mutable slice, like this:

However if you make the slice constant, then it works:

Just like string literals, {#syntax#}const{#endsyntax#} declarations, when the value is known at {#link|comptime#}, are stored in the global constant data section. Also {#link|Compile Time Variables#} are stored in the global constant data section.

{#syntax#}var{#endsyntax#} declarations inside functions are stored in the function's stack frame. Once a function returns, any {#link|Pointers#} to variables in the function's stack frame become invalid references, and dereferencing them becomes unchecked {#link|Undefined Behavior#}.

{#syntax#}var{#endsyntax#} declarations at the top level or in {#link|struct#} declarations are stored in the global data section.

The location of memory allocated with {#syntax#}allocator.alloc{#endsyntax#} or {#syntax#}allocator.create{#endsyntax#} is determined by the allocator's implementation.

TODO: thread local variables

Zig programmers can implement their own allocators by fulfilling the Allocator interface. In order to do this one must read carefully the documentation comments in std/mem.zig and then supply a {#syntax#}allocFn{#endsyntax#} and a {#syntax#}resizeFn{#endsyntax#}.

There are many example allocators to look at for inspiration. Look at std/heap.zig and {#syntax#}std.heap.GeneralPurposeAllocator{#endsyntax#}.

Many programming languages choose to handle the possibility of heap allocation failure by unconditionally crashing. By convention, Zig programmers do not consider this to be a satisfactory solution. Instead, {#syntax#}error.OutOfMemory{#endsyntax#} represents heap allocation failure, and Zig libraries return this error code whenever heap allocation failure prevented an operation from completing successfully.

Some have argued that because some operating systems such as Linux have memory overcommit enabled by default, it is pointless to handle heap allocation failure. There are many problems with this reasoning:

• Only some operating systems have an overcommit feature.
  • Linux has it enabled by default, but it is configurable.
  • Windows does not overcommit.
  • Embedded systems do not have overcommit.
  • Hobby operating systems may or may not have overcommit.
• For real-time systems, not only is there no overcommit, but typically the maximum amount of memory per application is determined ahead of time.
• When writing a library, one of the main goals is code reuse. By making code handle allocation failure correctly, a library becomes eligible to be reused in more contexts.
• Although some software has grown to depend on overcommit being enabled, its existence is the source of countless user experience disasters. When a system with overcommit enabled, such as Linux on default settings, comes close to memory exhaustion, the system locks up and becomes unusable. At this point, the OOM Killer selects an application to kill based on heuristics. This non-deterministic decision often results in an important process being killed, and often fails to return the system back to working order.

Recursion is a fundamental tool in modeling software. However it has an often-overlooked problem: unbounded memory allocation.

Recursion is an area of active experimentation in Zig and so the documentation here is not final. You can read a summary of recursion status in the 0.3.0 release notes.

The short summary is that currently recursion works normally as you would expect. Although Zig code is not yet protected from stack overflow, it is planned that a future version of Zig will provide such protection, with some degree of cooperation from Zig code required.

It is the Zig programmer's responsibility to ensure that a {#link|pointer|Pointers#} is not accessed when the memory pointed to is no longer available. Note that a {#link|slice|Slices#} is a form of pointer, in that it references other memory.

In order to prevent bugs, there are some helpful conventions to follow when dealing with pointers. In general, when a function returns a pointer, the documentation for the function should explain who "owns" the pointer. This concept helps the programmer decide when it is appropriate, if ever, to free the pointer.

For example, the function's documentation may say "caller owns the returned memory", in which case the code that calls the function must have a plan for when to free that memory. Probably in this situation, the function will accept an {#syntax#}Allocator{#endsyntax#} parameter.

Sometimes the lifetime of a pointer may be more complicated. For example, the {#syntax#}std.ArrayList(T).items{#endsyntax#} slice has a lifetime that remains valid until the next time the list is resized, such as by appending new elements.

The API documentation for functions and data structures should take great care to explain the ownership and lifetime semantics of pointers. Ownership determines whose responsibility it is to free the memory referenced by the pointer, and lifetime determines the point at which the memory becomes inaccessible (lest {#link|Undefined Behavior#} occur).

Compile variables are accessible by importing the {#syntax#}"builtin"{#endsyntax#} package, which the compiler makes available to every Zig source file. It contains compile-time constants such as the current target, endianness, and release mode.

Example of what is imported with {#syntax#}@import("builtin"){#endsyntax#}:

TODO: explain how root source file finds other files

TODO: pub fn main

TODO: pub fn panic

TODO: if linking with libc you can use export fn main

TODO: order independent top level declarations

TODO: lazy analysis

TODO: using comptime { _ = @import() }

The Zig Build System provides a cross-platform, dependency-free way to declare the logic required to build a project. With this system, the logic to build a project is written in a build.zig file, using the Zig Build System API to declare and configure build artifacts and other tasks.

Some examples of tasks the build system can help with:

• Creating build artifacts by executing the Zig compiler. This includes building Zig source code as well as C and C++ source code.
• Capturing user-configured options and using those options to configure the build.
• Surfacing build configuration as {#link|comptime#} values by providing a file that can be {#link|imported|@import#} by Zig code.
• Caching build artifacts to avoid unnecessarily repeating steps.
• Executing build artifacts or system-installed tools.
• Running tests and verifying the output of executing a build artifact matches the expected value.
• Running zig fmt on a codebase or a subset of it.
• Custom tasks.

To use the build system, run zig build --help to see a command-line usage help menu. This will include project-specific options that were declared in the build.zig script.

This build.zig file is automatically generated by zig init-exe.

This build.zig file is automatically generated by zig init-lib.

{#syntax#}
lib.addCSourceFile("src/lib.c", &[_][]const u8{
    "-Wall",
    "-Wextra",
    "-Werror",
});
      {#endsyntax#}

Although Zig is independent of C, and, unlike most other languages, does not depend on libc, Zig acknowledges the importance of interacting with existing C code.

There are a few ways that Zig facilitates C interop.

These have guaranteed C ABI compatibility and can be used like any other type.

• {#syntax#}c_short{#endsyntax#}
• {#syntax#}c_ushort{#endsyntax#}
• {#syntax#}c_int{#endsyntax#}
• {#syntax#}c_uint{#endsyntax#}
• {#syntax#}c_long{#endsyntax#}
• {#syntax#}c_ulong{#endsyntax#}
• {#syntax#}c_longlong{#endsyntax#}
• {#syntax#}c_ulonglong{#endsyntax#}
• {#syntax#}c_longdouble{#endsyntax#}

To interop with the C {#syntax#}void{#endsyntax#} type, use {#syntax#}anyopaque{#endsyntax#}.

The {#syntax#}@cImport{#endsyntax#} builtin function can be used to directly import symbols from .h files:

The {#syntax#}@cImport{#endsyntax#} function takes an expression as a parameter. This expression is evaluated at compile-time and is used to control preprocessor directives and include multiple .h files:

• -I: Specify a search directory for include files. May be used multiple times. Equivalent to clang's -I flag. The current directory is not included by default; use -I. to include it.
• -D: Define a preprocessor macro. Equivalent to clang's -D flag.
• -cflags [flags] --: Pass arbitrary additional command line flags to clang. Note: the list of flags must end with --
• -target: The {#link|target triple|Targets#} for the translated Zig code. If no target is specified, the current host target will be used.

Important! When translating C code with zig translate-c, you must use the same -target triple that you will use when compiling the translated code. In addition, you must ensure that the -cflags used, if any, match the cflags used by code on the target system. Using the incorrect -target or -cflags could result in clang or Zig parse failures, or subtle ABI incompatibilities when linking with C code.

{#syntax#}@cImport{#endsyntax#} and zig translate-c use the same underlying C translation functionality, so on a technical level they are equivalent. In practice, {#syntax#}@cImport{#endsyntax#} is useful as a way to quickly and easily access numeric constants, typedefs, and record types without needing any extra setup. If you need to pass {#link|cflags|Using -target and -cflags#} to clang, or if you would like to edit the translated code, it is recommended to use zig translate-c and save the results to a file. Common reasons for editing the generated code include: changing {#syntax#}anytype{#endsyntax#} parameters in function-like macros to more specific types; changing {#syntax#}[*c]T{#endsyntax#} pointers to {#syntax#}[*]T{#endsyntax#} or {#syntax#}*T{#endsyntax#} pointers for improved type safety; and {#link|enabling or disabling runtime safety|@setRuntimeSafety#} within specific functions.

The C translation feature (whether used via zig translate-c or {#syntax#}@cImport{#endsyntax#}) integrates with the Zig caching system. Subsequent runs with the same source file, target, and cflags will use the cache instead of repeatedly translating the same code.

To see where the cached files are stored when compiling code that uses {#syntax#}@cImport{#endsyntax#}, use the --verbose-cimport flag:

cimport.h contains the file to translate (constructed from calls to {#syntax#}@cInclude{#endsyntax#}, {#syntax#}@cDefine{#endsyntax#}, and {#syntax#}@cUndef{#endsyntax#}), cimport.h.d is the list of file dependencies, and cimport.zig contains the translated output.

Some C constructs cannot be translated to Zig - for example, goto, structs with bitfields, and token-pasting macros. Zig employs demotion to allow translation to continue in the face of non-translatable entities.

Demotion comes in three varieties - {#link|opaque#}, extern, and {#syntax#}@compileError{#endsyntax#}. C structs and unions that cannot be translated correctly will be translated as {#syntax#}opaque{}{#endsyntax#}. Functions that contain opaque types or code constructs that cannot be translated will be demoted to {#syntax#}extern{#endsyntax#} declarations. Thus, non-translatable types can still be used as pointers, and non-translatable functions can be called so long as the linker is aware of the compiled function.

{#syntax#}@compileError{#endsyntax#} is used when top-level definitions (global variables, function prototypes, macros) cannot be translated or demoted. Since Zig uses lazy analysis for top-level declarations, untranslatable entities will not cause a compile error in your code unless you actually use them.

C Translation makes a best-effort attempt to translate function-like macros into equivalent Zig functions. Since C macros operate at the level of lexical tokens, not all C macros can be translated to Zig. Macros that cannot be translated will be be demoted to {#syntax#}@compileError{#endsyntax#}. Note that C code which uses macros will be translated without any additional issues (since Zig operates on the pre-processed source with macros expanded). It is merely the macros themselves which may not be translatable to Zig.

Consider the following example:

Note that {#syntax#}foo{#endsyntax#} was translated correctly despite using a non-translatable macro. {#syntax#}MAKELOCAL{#endsyntax#} was demoted to {#syntax#}@compileError{#endsyntax#} since it cannot be expressed as a Zig function; this simply means that you cannot directly use {#syntax#}MAKELOCAL{#endsyntax#} from Zig.

This type is to be avoided whenever possible. The only valid reason for using a C pointer is in auto-generated code from translating C code.

When importing C header files, it is ambiguous whether pointers should be translated as single-item pointers ({#syntax#}*T{#endsyntax#}) or many-item pointers ({#syntax#}[*]T{#endsyntax#}). C pointers are a compromise so that Zig code can utilize translated header files directly.

{#syntax#}[*c]T{#endsyntax#} - C pointer.

• Supports all the syntax of the other two pointer types.
• Coerces to other pointer types, as well as {#link|Optional Pointers#}. When a C pointer is coerced to a non-optional pointer, safety-checked {#link|Undefined Behavior#} occurs if the address is 0.
• Allows address 0. On non-freestanding targets, dereferencing address 0 is safety-checked {#link|Undefined Behavior#}. Optional C pointers introduce another bit to keep track of null, just like {#syntax#}?usize{#endsyntax#}. Note that creating an optional C pointer is unnecessary as one can use normal {#link|Optional Pointers#}.
• Supports {#link|Type Coercion#} to and from integers.
• Supports comparison with integers.
• Does not support Zig-only pointer attributes such as alignment. Use normal {#link|Pointers#} please!

When a C pointer is pointing to a single struct (not an array), dereference the C pointer to access to the struct's fields or member data. That syntax looks like this:

{#syntax#}ptr_to_struct.*.struct_member{#endsyntax#}

This is comparable to doing {#syntax#}->{#endsyntax#} in C.

When a C pointer is pointing to an array of structs, the syntax reverts to this:

{#syntax#}ptr_to_struct_array[index].struct_member{#endsyntax#}

One of the primary use cases for Zig is exporting a library with the C ABI for other programming languages to call into. The {#syntax#}export{#endsyntax#} keyword in front of functions, variables, and types causes them to be part of the library API:

To make a static library:

To make a shared library:

Here is an example with the {#link|Zig Build System#}:

{#syntax#}align{#endsyntax#}

{#syntax#}allowzero{#endsyntax#}

{#syntax#}and{#endsyntax#}

{#syntax#}anyframe{#endsyntax#}

{#syntax#}anytype{#endsyntax#}

{#syntax#}asm{#endsyntax#}

{#syntax#}async{#endsyntax#}

{#syntax#}await{#endsyntax#}

{#syntax#}break{#endsyntax#}

{#syntax#}catch{#endsyntax#}

{#syntax#}comptime{#endsyntax#}

{#syntax#}const{#endsyntax#}

{#syntax#}continue{#endsyntax#}

{#syntax#}defer{#endsyntax#}

{#syntax#}else{#endsyntax#}

{#syntax#}enum{#endsyntax#}

{#syntax#}errdefer{#endsyntax#}

{#syntax#}error{#endsyntax#}

{#syntax#}export{#endsyntax#}

{#syntax#}extern{#endsyntax#}

{#syntax#}fn{#endsyntax#}

{#syntax#}for{#endsyntax#}

{#syntax#}if{#endsyntax#}

{#syntax#}inline{#endsyntax#}

{#syntax#}noalias{#endsyntax#}

{#syntax#}nosuspend{#endsyntax#}

{#syntax#}or{#endsyntax#}

{#syntax#}orelse{#endsyntax#}

{#syntax#}packed{#endsyntax#}

{#syntax#}pub{#endsyntax#}

{#syntax#}resume{#endsyntax#}

{#syntax#}return{#endsyntax#}

{#syntax#}linksection{#endsyntax#}

{#syntax#}struct{#endsyntax#}

{#syntax#}suspend{#endsyntax#}

{#syntax#}switch{#endsyntax#}

{#syntax#}test{#endsyntax#}

{#syntax#}threadlocal{#endsyntax#}

{#syntax#}try{#endsyntax#}

{#syntax#}union{#endsyntax#}

{#syntax#}unreachable{#endsyntax#}

{#syntax#}usingnamespace{#endsyntax#}

{#syntax#}var{#endsyntax#}

{#syntax#}volatile{#endsyntax#}

{#syntax#}while{#endsyntax#}