Documentation - The Zig Programming Language
Documentation - The Zig Programming Language
Zig Version
0.1.1 | 0.2.0 | 0.3.0 | 0.4.0 | 0.5.0 | 0.6.0 | 0.7.1 | 0.8.1 | 0.9.1 | 0.10.1 | 0.11.0 | 0.12.0 | 0.13.0 | 0.14.1
| master
Table of Contents
• Introduction
• Zig Standard Library
• Hello World
• Comments
◦ Doc Comments
◦ Top-Level Doc Comments
• Values
◦ Primitive Types
◦ Primitive Values
◦ String Literals and Unicode Code Point Literals
▪ Escape Sequences
▪ Multiline String Literals
◦ Assignment
▪ undefined
▪ Destructuring
• Zig Test
◦ Test Declarations
▪ Doctests
◦ Test Failure
◦ Skip Tests
◦ Report Memory Leaks
◦ Detecting Test Build
◦ Test Output and Logging
◦ The Testing Namespace
◦ Test Tool Documentation
• Variables
◦ Identifiers
◦ Container Level Variables
◦ Static Local Variables
◦ Thread Local Variables
◦ Local Variables
• Integers
◦ Integer Literals
◦ Runtime Integer Values
• Floats
◦ Float Literals
◦ Floating Point Operations
• Operators
◦ Table of Operators
◦ Precedence
• Arrays
◦ Multidimensional Arrays
◦ Sentinel-Terminated Arrays
◦ Destructuring Arrays
• Vectors
◦ Destructuring Vectors
• Pointers
◦ volatile
◦ Alignment
◦ allowzero
◦ Sentinel-Terminated Pointers
• Slices
◦ Sentinel-Terminated Slices
• struct
◦ Default Field Values
▪ Faulty Default Field Values
◦ extern struct
◦ packed struct
◦ Struct Naming
◦ Anonymous Struct Literals
◦ Tuples
▪ Destructuring Tuples
• enum
◦ extern enum
◦ Enum Literals
◦ Non-exhaustive enum
• union
◦ Tagged union
◦ extern union
◦ packed union
◦ Anonymous Union Literals
• opaque
• Blocks
◦ Shadowing
◦ Empty Blocks
• switch
◦ Exhaustive Switching
◦ Switching with Enum Literals
◦ Labeled switch
◦ Inline Switch Prongs
• while
◦ Labeled while
◦ while with Optionals
◦ while with Error Unions
◦ inline while
• for
◦ Labeled for
◦ inline for
• if
◦ if with Optionals
• defer
• unreachable
◦ Basics
◦ At Compile-Time
• noreturn
• Functions
◦ Pass-by-value Parameters
◦ Function Parameter Type Inference
◦ inline fn
◦ Function Reflection
• Errors
◦ Error Set Type
▪ The Global Error Set
◦ Error Union Type
▪ catch
▪ try
▪ errdefer
▪ Merging Error Sets
▪ Inferred Error Sets
◦ Error Return Traces
▪ Implementation Details
• Optionals
◦ Optional Type
◦ null
◦ Optional Pointers
• Casting
◦ Type Coercion
▪ Type Coercion: Stricter Qualification
▪ Type Coercion: Integer and Float Widening
▪ Type Coercion: Float to Int
▪ Type Coercion: Slices, Arrays and Pointers
▪ Type Coercion: Optionals
▪ Type Coercion: Error Unions
▪ Type Coercion: Compile-Time Known Numbers
▪ Type Coercion: Unions and Enums
▪ Type Coercion: undefined
▪ Type Coercion: Tuples to Arrays
◦ Explicit Casts
◦ Peer Type Resolution
• Zero Bit Types
◦ void
• Result Location Semantics
◦ Result Types
◦ Result Locations
• comptime
◦ Introducing the Compile-Time Concept
▪ Compile-Time Parameters
▪ Compile-Time Variables
▪ Compile-Time Expressions
◦ Generic Data Structures
◦ Case Study: print in Zig
• Assembly
◦ Output Constraints
◦ Input Constraints
◦ Clobbers
◦ Global Assembly
• Atomics
• Async Functions
• Builtin Functions
◦ @addrSpaceCast ◦ @bitCast
◦ @addWithOverflow ◦ @bitOffsetOf
◦ @alignCast ◦ @bitSizeOf
◦ @alignOf ◦ @branchHint
◦ @as ◦ @breakpoint
◦ @atomicLoad ◦ @mulAdd
◦ @atomicRmw ◦ @byteSwap
◦ @atomicStore ◦ @bitReverse
◦ @offsetOf ◦ @intFromFloat
◦ @call ◦ @intFromPtr
◦ @cDefine ◦ @max
◦ @cImport ◦ @memcpy
◦ @cInclude ◦ @memset
◦ @clz ◦ @memmove
◦ @cmpxchgStrong ◦ @min
◦ @cmpxchgWeak ◦ @wasmMemorySize
◦ @compileError ◦ @wasmMemoryGrow
◦ @compileLog ◦ @mod
◦ @constCast ◦ @mulWithOverflow
◦ @ctz ◦ @panic
◦ @cUndef ◦ @popCount
◦ @cVaArg ◦ @prefetch
◦ @cVaCopy ◦ @ptrCast
◦ @cVaEnd ◦ @ptrFromInt
◦ @cVaStart ◦ @rem
◦ @divExact ◦ @returnAddress
◦ @divFloor ◦ @select
◦ @divTrunc ◦ @setEvalBranchQuota
◦ @embedFile ◦ @setFloatMode
◦ @enumFromInt ◦ @setRuntimeSafety
◦ @errorFromInt ◦ @shlExact
◦ @errorName ◦ @shlWithOverflow
◦ @errorReturnTrace ◦ @shrExact
◦ @errorCast ◦ @shuffle
◦ @export ◦ @sizeOf
◦ @extern ◦ @splat
◦ @field ◦ @reduce
◦ @fieldParentPtr ◦ @src
◦ @FieldType ◦ @sqrt
◦ @floatCast ◦ @sin
◦ @floatFromInt ◦ @cos
◦ @frameAddress ◦ @tan
◦ @hasDecl ◦ @exp
◦ @hasField ◦ @exp2
◦ @import ◦ @log
◦ @inComptime ◦ @log2
◦ @intCast ◦ @log10
◦ @intFromBool ◦ @abs
◦ @intFromEnum ◦ @floor
◦ @intFromError ◦ @ceil
◦ @trunc ◦ @typeName
◦ @round ◦ @TypeOf
◦ @subWithOverflow ◦ @unionInit
◦ @tagName ◦ @Vector
◦ @This ◦ @volatileCast
◦ @trap ◦ @workGroupId
◦ @truncate ◦ @workGroupSize
◦ @Type ◦ @workItemId
◦ @typeInfo
• Build Mode
◦ Debug
◦ ReleaseFast
◦ ReleaseSafe
◦ ReleaseSmall
• Single Threaded Builds
• Illegal Behavior
◦ Reaching Unreachable Code
◦ Index out of Bounds
◦ Cast Negative Number to Unsigned Integer
◦ Cast Truncates Data
◦ Integer Overflow
▪ Default Operations
▪ Standard Library Math Functions
▪ Builtin Overflow Functions
▪ Wrapping Operations
◦ Exact Left Shift Overflow
◦ Exact Right Shift Overflow
◦ Division by Zero
◦ Remainder Division by Zero
◦ Exact Division Remainder
◦ Attempt to Unwrap Null
◦ Attempt to Unwrap Error
◦ Invalid Error Code
◦ Invalid Enum Cast
◦ Invalid Error Set Cast
◦ Incorrect Pointer Alignment
◦ Wrong Union Field Access
◦ Out of Bounds Float to Integer Cast
◦ Pointer Cast Invalid Null
• Memory
◦ Choosing an Allocator
◦ Where are the bytes?
◦ Implementing an Allocator
◦ Heap Allocation Failure
◦ Recursion
◦ Lifetime and Ownership
• Compile Variables
• Compilation Model
◦ Source File Structs
◦ File and Declaration Discovery
◦ Special Root Declarations
▪ Entry Point
▪ Standard Library Options
▪ Panic Handler
• Zig Build System
•C
◦ C Type Primitives
◦ Import from C Header File
◦ C Translation CLI
▪ Command line flags
▪ Using -target and -cflags
▪ @cImport vs translate-c
◦ C Translation Caching
◦ Translation failures
◦ C Macros
◦ C Pointers
◦ C Variadic Functions
◦ Exporting a C Library
◦ Mixing Object Files
• WebAssembly
◦ Freestanding
◦ WASI
• Targets
• Style Guide
◦ Avoid Redundancy in Names
◦ Avoid Redundant Names in Fully-Qualified Namespaces
◦ Whitespace
◦ Names
◦ Examples
◦ Doc Comment Guidance
• Source Encoding
• Keyword Reference
• Appendix
◦ Containers
◦ Grammar
◦ Zen
Introduction
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and
reusable software.
Robust
Behavior is correct even for edge cases such as out of memory.
Optimal
Write programs the best way they can behave and perform.
Reusable
The same code works in many environments which have different constraints.
Maintainable
Precisely communicate intent to the compiler and other programmers. The language imposes a
low overhead to reading code and is resilient to changing requirements and environments.
Often the most efficient way to learn something new is to see examples, so this documentation shows
how to use each of Zig's features. It is all on one page so you can search with your browser's search
tool.
The code samples in this document are compiled and tested as part of the main test suite of Zig.
This HTML document depends on no external files, so you can use it offline.
Zig's Standard Library contains commonly used algorithms, data structures, and definitions to help you
build programs or libraries. You will see many examples of Zig's Standard Library used in this
documentation. To learn more about the Zig Standard Library, visit the link above.
Alternatively, the Zig Standard Library documentation is provided with each Zig distribution. It can be
rendered via a local webserver with:
Shell
zig std
Hello World
hello.zig
const std = @import("std");
Shell
$ zig build-exe hello.zig
$ ./hello
Hello, World!
Most of the time, it is more appropriate to write to stderr rather than stdout, and whether or not the
message is successfully written to the stream is irrelevant. Also, formatted printing often comes in
handy. For this common case, there is a simpler API:
hello_again.zig
const std = @import("std");
Shell
$ zig build-exe hello_again.zig
$ ./hello_again
Hello, World!
In this case, the ! may be omitted from the return type of main because no errors are returned
from the function.
See also:
• Values
• Tuples
• @import
• Errors
• Entry Point
• Source Encoding
• try
Comments
Zig supports 3 types of comments. Normal comments are ignored, but doc comments and top-level
doc comments are used by the compiler to generate the package documentation.
Shell
zig test -femit-docs main.zig
comments.zig
const print = @import("std").debug.print;
��print("Hello?", .{});
Shell
$ zig build-exe comments.zig
$ ./comments
Hello, world!
There are no multiline comments in Zig (e.g. like �� �� comments in C). This allows Zig to have the
property that each line of code can be tokenized out of context.
Doc Comments
A doc comment is one that begins with exactly three slashes (i.e. ��� but not //// ); multiple doc
comments in a row are merged together to form a multiline doc comment. The doc comment
documents whatever immediately follows it.
doc_comments.zig
��� A structure for storing a timestamp, with nanosecond precision (this is
��� multiline doc comment).
const Timestamp = struct {
��� The number of seconds since the epoch (this is also a doc comment).
seconds: i64, �� signed so we can represent pre-1970 (not a doc comment)
��� The number of nanoseconds past the second (doc comment again).
nanos: u32,
��� Returns a `Timestamp` struct representing the Unix epoch; that is, t
��� moment of 1970 Jan 1 00�00�00 UTC (this is a doc comment too).
pub fn unixEpoch() Timestamp {
return Timestamp{
.seconds = 0,
.nanos = 0,
};
}
};
Doc comments are only allowed in certain places; it is a compile error to have a doc comment in an
unexpected place, such as in the middle of an expression, or just before a non-doc comment.
invalid_doc-comment.zig
��� doc-comment
��! top-level doc-comment
const std = @import("std");
Shell
$ zig build-obj invalid_doc-comment.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/invalid_doc-comm
��� doc-comment
^
unattached_doc-comment.zig
pub fn main() void {}
Shell
$ zig build-obj unattached_doc-comment.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/unattached_doc-c
��� End of file
^~~~~~~~~~~~~~~
Doc comments can be interleaved with normal comments. Currently, when producing the package
documentation, normal comments are merged with doc comments.
A top-level doc comment is one that begins with two slashes and an exclamation point: ��! ; it
documents the current module.
It is a compile error if a top-level doc comment is not placed at the start of a container, before any
expressions.
tldoc_comments.zig
��! This module provides functions for retrieving the current date and
��! time with varying degrees of precision and accuracy. It does not
��! depend on libc, but will use functions from it if available.
const S = struct {
��! Top level comments are allowed inside a container other than a modul
��! but it is not very useful. Currently, when producing the package
��! documentation, these comments are ignored.
};
Values
values.zig
�� Top-level declarations are order-independent:
const print = std.debug.print;
const std = @import("std");
const os = std.os;
const assert = std.debug.assert;
�� floats
const seven_div_three: f32 = 7.0 / 3.0;
print("7.0 / 3.0 = {}\n", .{seven_div_three});
�� boolean
print("{}\n{}\n{}\n", .{
true and false,
true or false,
!true,
});
�� optional
var optional_value: ?[]const u8 = null;
assert(optional_value �� null);
optional_value = "hi";
assert(optional_value �� null);
print("\noptional 2\ntype: {}\nvalue: {?s}\n", .{
@TypeOf(optional_value), optional_value,
});
�� error union
var number_or_error: anyerror!i32 = error.ArgNotFound;
number_or_error = 1234;
Shell
$ zig build-exe values.zig
$ ./values
1 + 1 = 2
7.0 / 3.0 = 2.3333333
false
true
false
optional 1
type: ?[]const u8
value: null
optional 2
type: ?[]const u8
value: hi
error union 1
type: anyerror!i32
value: error.ArgNotFound
error union 2
type: anyerror!i32
value: 1234
Primitive Types
Primitive Types
unsigned
u128 unsigned 128-bit integer
��int128
uintptr_t ,
usize unsigned pointer sized integer. Also see #5185
size_t
unsigned
c_ushort for ABI compatibility with C
short
unsigned long
c_ulonglong for ABI compatibility with C
long
Type C Equivalent Description
In addition to the integer types above, arbitrary bit-width integers can be referenced by using an
identifier of i or u followed by digits. For example, the identifier i7 refers to a signed 7-bit
integer. The maximum allowed bit-width of an integer type is 65535 .
See also:
• Integers
• Floats
• void
• Errors
• @Type
Primitive Values
Primitive Values
Name Description
See also:
• Optionals
• undefined
String literals are constant single-item Pointers to null-terminated byte arrays. The type of string
literals encodes both the length, and the fact that they are null-terminated, and thus they can be
coerced to both Slices and Null-Terminated Pointers. Dereferencing string literals converts them to
Arrays.
Because Zig source code is UTF-8 encoded, any non-ASCII bytes appearing within a string literal in
source code carry their UTF-8 meaning into the content of the string in the Zig program; the bytes are
not modified by the compiler. It is possible to embed non-UTF-8 bytes into a string literal using \xNN
notation.
Indexing into a string containing non-ASCII bytes returns individual bytes, whether valid UTF-8 or not.
Unicode code point literals have type comptime_int , the same as Integer Literals. All Escape
Sequences are valid in both string literals and Unicode code point literals.
string_literals.zig
const print = @import("std").debug.print;
const mem = @import("std").mem; �� will be used to compare bytes
Shell
$ zig build-exe string_literals.zig
$ ./string_literals
*const [5�0]u8
5
e
0
true
128169
128175
true
true
0xfe
0x9f
See also:
• Arrays
• Source Encoding
Escape Sequences
Escape Sequences
\n Newline
\r Carriage Return
\t Tab
\\ Backslash
Multiline string literals have no escapes and can span across multiple lines. To start a multiline string
literal, use the \\ token. Just like a comment, the string literal goes until the end of the line. The end
of the line is not included in the string literal. However, if the next line begins with \\ then a newline
is appended and the string literal continues.
multiline_string_literals.zig
const hello_world_in_c =
\\#include <stdio.h>
\\
\\int main(int argc, char **argv) {
\\ printf("hello world\n");
\\ return 0;
\\}
;
See also:
• @embedFile
Assignment
constant_identifier_cannot_change.zig
const x = 1234;
fn foo() void {
�� It works at file scope as well as inside functions.
const y = 5678;
Shell
$ zig build-exe constant_identifier_cannot_change.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/constant_identif
y += 1;
^
referenced by:
main: /home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/consta
callMain [inlined]: /home/ci/actions-runner/_work/zig-bootstrap/out/host
callMainWithArgs [inlined]: /home/ci/actions-runner/_work/zig-bootstrap/
posixCallMainAndExit: /home/ci/actions-runner/_work/zig-bootstrap/out/ho
2 reference(s) hidden; use '-freference-trace=6' to see all references
const applies to all of the bytes that the identifier immediately addresses. Pointers have their own
const-ness.
If you need a variable that you can modify, use the var keyword:
mutable_var.zig
const print = @import("std").debug.print;
y += 1;
print("{d}", .{y});
}
Shell
$ zig build-exe mutable_var.zig
$ ./mutable_var
5679
var_must_be_initialized.zig
pub fn main() void {
var x: i32;
x = 1;
}
Shell
$ zig build-exe var_must_be_initialized.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/var_must_be_init
var x: i32;
^
undefined
assign_undefined.zig
const print = @import("std").debug.print;
Shell
$ zig build-exe assign_undefined.zig
$ ./assign_undefined
1
undefined can be coerced to any type. Once this happens, it is no longer possible to detect that
the value is undefined . undefined means the value could be anything, even something that is
nonsense according to the type. Translated into English, undefined means "Not a meaningful
value. Using this value would be a bug. The value will be unused, or overwritten before being used."
In Debug and ReleaseSafe mode, Zig writes 0xaa bytes to undefined memory. This is to catch bugs
early, and to help detect use of undefined memory in a debugger. However, this behavior is only an
implementation feature, not a language semantic, so it is not guaranteed to be observable to code.
Destructuring
A destructuring assignment can separate elements of indexable aggregate types (Tuples, Arrays,
Vectors):
destructuring_to_existing.zig
const print = @import("std").debug.print;
pub fn main() void {
var x: u32 = undefined;
var y: u32 = undefined;
var z: u32 = undefined;
const tuple = .{ 1, 2, 3 };
x, y, z = tuple;
x, y, z = array;
x, y, z = vector;
Shell
$ zig build-exe destructuring_to_existing.zig
$ ./destructuring_to_existing
tuple: x = 1, y = 2, z = 3
array: x = 4, y = 5, z = 6
vector: x = 7, y = 8, z = 9
A destructuring expression may only appear within a block (i.e. not at container scope). The left hand
side of the assignment must consist of a comma separated list, each element of which may be either
an lvalue (for instance, an existing `var`) or a variable declaration:
destructuring_mixed.zig
const print = @import("std").debug.print;
const tuple = .{ 1, 2, 3 };
�� y is mutable
y = 100;
Shell
$ zig build-exe destructuring_mixed.zig
$ ./destructuring_mixed
x = 1, y = 2, z = 3
x = 2
A destructure may be prefixed with the comptime keyword, in which case the entire destructure
expression is evaluated at comptime. All var s declared would be comptime var s and all
expressions (both result locations and the assignee expression) are evaluated at comptime.
See also:
• Destructuring Tuples
• Destructuring Arrays
• Destructuring Vectors
Zig Test
Code written within one or more test declarations can be used to ensure behavior meets
expectations:
testing_introduction.zig
const std = @import("std");
test addOne {
�� A test name can also be written using an identifier.
�� This is a doctest, and serves as documentation for `addOne`.
try std.testing.expect(addOne(41) �� 42);
}
��� The function `addOne` adds one to the number given as its argument.
fn addOne(number: i32) i32 {
return number + 1;
}
Shell
$ zig test testing_introduction.zig
1/2 testing_introduction.test.expect addOne adds one to 41���OK
2/2 testing_introduction.decltest.addOne���OK
All 2 tests passed.
The testing_introduction.zig code sample tests the function addOne to ensure that it
returns 42 given the input 41 . From this test's perspective, the addOne 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 Zig Standard Library as its main entry point.
During the build, test declarations found while resolving the given Zig source file are included for
the default test runner to run and report on.
This documentation discusses the features of the default test runner as provided by the Zig
Standard Library. Its source code is located in lib/compiler/test_runner.zig .
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 Declarations
Test declarations contain the keyword test , followed by an optional name written as a string literal
or an identifier, followed by a block containing any valid Zig code that is allowed in a function.
Non-named test blocks always run during test builds and are exempt from Skip Tests.
Test declarations are similar to Functions: they have a return type and a block of code. The implicit
return type of test is the Error Union Type anyerror!void , 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.
See also:
Doctests
Test declarations named using an identifier are doctests. The identifier must refer to another
declaration in scope. A doctest, like a doc comment, serves as documentation for the associated
declaration, and will appear in the generated documentation for the declaration.
An effective doctest should be self-contained and focused on the declaration being tested, answering
questions a new user might have about its interface or intended usage, while avoiding unnecessary or
confusing details. A doctest is not a substitute for a doc comment, but rather a supplement and
companion providing a testable, code-driven example, verified by zig test.
Test Failure
The default test runner checks for an error returned from a test. When a test returns an error, the test is
considered a failure and its error return trace is output to standard error. The total number of failures
will be reported after all tests have run.
testing_failure.zig
const std = @import("std");
Shell
$ zig test testing_failure.zig
1/2 testing_failure.test.expect this to fail���FAIL (TestUnexpectedResult)
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/testing.zig
if (!ok) return error.TestUnexpectedResult;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/testing_failure.
try std.testing.expect(false);
^
2/2 testing_failure.test.expect this to succeed���OK
1 passed; 0 skipped; 1 failed.
error: the following test command failed with exit code 1:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/374344ce33
Skip Tests
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 test return the error error.SkipZigTest 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.
testing_skip.zig
test "this will be skipped" {
return error.SkipZigTest;
}
Shell
$ zig test testing_skip.zig
1/1 testing_skip.test.this will be skipped���SKIP
0 passed; 1 skipped; 0 failed.
When code allocates Memory using the Zig Standard Library's testing allocator,
std.testing.allocator , the default test runner will report any leaks that are found from using
the testing allocator:
testing_detect_leak.zig
const std = @import("std");
Shell
$ zig test testing_detect_leak.zig
1/1 testing_detect_leak.test.detect leak���OK
[gpa] (err): memory address 0x7fae16b00000 leaked:
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/array_list.
const new_memory = try self.allocator.alignedAlloc(T, alignm
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/array_list.
return self.ensureTotalCapacityPrecise(better_capacity);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/array_list.
try self.ensureTotalCapacity(newlen);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/array_list.
const new_item_ptr = try self.addOne();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/testing_detect_l
try list.append(' ');
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
See also:
• defer
• Memory
testing_detect_test.zig
const std = @import("std");
const builtin = @import("builtin");
const expect = std.testing.expect;
test "builtin.is_test" {
try expect(isATest());
}
fn isATest() bool {
return builtin.is_test;
}
Shell
$ zig test testing_detect_test.zig
1/1 testing_detect_test.test.builtin.is_test���OK
All 1 tests passed.
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:
testing_namespace.zig
const std = @import("std");
Shell
$ zig test testing_namespace.zig
1/2 testing_namespace.test.expectEqual demo���OK
2/2 testing_namespace.test.expectError demo���OK
All 2 tests passed.
The Zig Standard Library also contains functions to compare Slices, strings, and more. See the rest of
the std.testing namespace in the 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.
Variables
A variable is a unit of Memory storage.
It is generally preferable to use const rather than var when declaring a variable. This causes less
work for both humans and computers to do when reading code, and creates more optimization
opportunities.
The extern keyword or @extern builtin function can be used to link against a variable that is
exported from another object. The export keyword or @export builtin function can be used to make
a variable available to other objects at link time. In both cases, the type of the variable must be C ABI
compatible.
See also:
• Exporting a C Library
Identifiers
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 Keyword
Reference.
If a name that does not fit these requirements is needed, such as for linking with external libraries, the
@"" syntax may be used.
identifiers.zig
const @"identifier with spaces in it" = 0xff;
const @"1SmallStep4Man" = 112358;
const c = @import("std").c;
pub extern "c" fn @"error"() void;
pub extern "c" fn @"fstat$INODE64"(fd: c.fd_t, buf: *c.Stat) c_int;
Container level variables have static lifetime and are order-independent and lazily analyzed. The
initialization value of container level variables is implicitly comptime. If a container level variable is
const then its value is comptime -known, otherwise it is runtime-known.
test_container_level_variables.zig
var y: i32 = add(10, x);
const x: i32 = add(12, 34);
Shell
$ zig test test_container_level_variables.zig
1/1 test_container_level_variables.test.container level variables���OK
All 1 tests passed.
Container level variables may be declared inside a struct, union, enum, or opaque:
test_namespaced_container_level_variable.zig
const std = @import("std");
const expect = std.testing.expect;
const S = struct {
var x: i32 = 1234;
};
fn foo() i32 {
S.x += 1;
return S.x;
}
Shell
$ zig test test_namespaced_container_level_variable.zig
1/1 test_namespaced_container_level_variable.test.namespaced container level
All 1 tests passed.
It is also possible to have local variables with static lifetime by using containers inside functions.
test_static_local_variable.zig
const std = @import("std");
const expect = std.testing.expect;
fn foo() i32 {
const S = struct {
var x: i32 = 1234;
};
S.x += 1;
return S.x;
}
Shell
$ zig test test_static_local_variable.zig
1/1 test_static_local_variable.test.static local variable���OK
All 1 tests passed.
A variable may be specified to be a thread-local variable using the threadlocal keyword, which
makes each thread work with a separate instance of the variable:
test_thread_local_variables.zig
const std = @import("std");
const assert = std.debug.assert;
fn testTls() void {
assert(x �� 1234);
x += 1;
assert(x �� 1235);
}
Shell
$ zig test test_thread_local_variables.zig
1/1 test_thread_local_variables.test.thread local storage���OK
All 1 tests passed.
For Single Threaded Builds, all thread local variables are treated as regular Container Level Variables.
Local Variables
Local variables occur inside Functions, comptime blocks, and @cImport blocks.
When a local variable is const , it means that after initialization, the variable's value will not change.
If the initialization value of a const variable is comptime-known, then the variable is also
comptime -known.
A local variable may be qualified with the comptime keyword. This causes the variable's value to be
comptime -known, and all loads and stores of the variable to happen during semantic analysis of the
program, rather than at runtime. All variables declared in a comptime expression are implicitly
comptime variables.
test_comptime_variables.zig
const std = @import("std");
const expect = std.testing.expect;
x += 1;
y += 1;
if (y �� 2) {
�� This compile error never triggers because y is a comptime variabl
�� and so `y �� 2` is a comptime value, and this if is statically ev
@compileError("wrong y value");
}
}
Shell
$ zig test test_comptime_variables.zig
1/1 test_comptime_variables.test.comptime vars���OK
All 1 tests passed.
Integers
Integer Literals
integer_literals.zig
const decimal_int = 98222;
const hex_int = 0xff;
const another_hex_int = 0xFF;
const octal_int = 0o755;
const binary_int = 0b11110000;
Integer literals have no size limitation, and if any Illegal 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 safety-checked Illegal Behavior.
runtime_vs_comptime.zig
fn divide(a: i32, b: i32) i32 {
return a / b;
}
In this function, values a and b are known only at runtime, and thus this division operation is
vulnerable to both Integer Overflow and Division by Zero.
Operators such as + and - cause Illegal Behavior on integer overflow. Alternative operators are
provided for wrapping and saturating arithmetic on all targets. +% and -% perform wrapping
arithmetic while +| and �� perform saturating arithmetic.
See also:
• Wrapping Operations
Floats
Zig has the following floating point types:
Float Literals
Float literals have type comptime_float which is guaranteed to have the same precision and
operations of the largest other floating point type, which is f128 .
Float literals coerce to any floating point type, and to any integer type when there is no fractional
component.
float_literals.zig
const floating_point = 123.0E+77;
const another_float = 123.0;
const yet_another = 123.0e+77;
There is no syntax for NaN, infinity, or negative infinity. For these special values, one must use the
standard library:
float_special_values.zig
const std = @import("std");
By default floating point operations use Strict mode, but you can switch to Optimized mode
on a per-block basis:
float_mode_obj.zig
const std = @import("std");
const big = @as(f64, 1 �� 40);
Shell
$ zig build-obj float_mode_obj.zig -O ReleaseFast
For this test we have to separate code into two object files - otherwise the optimizer figures out all the
values at compile-time, which operates in strict mode.
float_mode_exe.zig
const print = @import("std").debug.print;
See also:
• @setFloatMode
• Division by Zero
Operators
There is no operator overloading. When you see an operator in Zig, you know that it is doing something
from this table, and nothing else.
Table of Operators
Addition
Integers Can cause overflow for integers.
a + b 2 + 5 ��
a += b Floats Invokes Peer Type Resolution
for the operands.
Name Syntax Types Remarks
See also @addWithOverflow.
Twos-complement wrapping
behavior.
Wrapping a +% b Integers Invokes Peer Type Resolution @as(u32
Addition a +%= b for the operands.
Twos-complement wrapping
behavior.
Wrapping a -% b Integers Invokes Peer Type Resolution @as(u8
Subtraction a -%= b for the operands.
Integers
-a Can cause overflow for integers. -1 ��
Negation
Floats
Name Syntax Types Remarks
Twos-complement wrapping
behavior.
Wrapping a *% b Integers Invokes Peer Type Resolution @as(u8
Multiplication a *%= b for the operands.
b must be comptime-known
a �� b Integers or have a type with log2 number
Bit Shift Left 0b1 ��
a ��� b of bits as a .
~a Integers �as(u8
Bitwise Not
If a is null , returns b
Defaulting ("default value"), otherwise const value:
a orelse b Optionals const unwrapp
Optional returns the unwrapped value of
Unwrap a . Note that b may be a unwrapped ��
value of type noreturn.
Equivalent to:
Optional Optionals const value:
a��
Unwrap a orelse unreachable value�� ��
If a is an error , returns b
("default value"), otherwise
Error returns the unwrapped value of const value:
Defaulting a catch b
Unions a . Note that b may be a const unwrapp
Error Unwrap a catch |err| b
value of type noreturn. err is unwrapped ��
the error and is in scope of
the expression b .
If a is false , returns
a and b bool false without evaluating (false
Logical And
b . Otherwise, returns b .
Name Syntax Types Remarks
!a bool !false
Boolean Not
Integers
Floats
Returns true if a and b are
bool equal, otherwise returns
Equality a �� b (1 ��
type false . Invokes Peer Type
Resolution for the operands.
packed
struct
Integers
Returns false if a and b are
Floats
equal, otherwise returns
Inequality a �� b (1 ��
bool true . Invokes Peer Type
Resolution for the operands.
type
const mem =
Only available when the lengths const array1
Array Arrays of both a and b are compile-
a �� b const array2
Concatenation time known.
const togethe
mem.eql(
const x:
Pointer Pointers
a.* Pointer dereference. const ptr = &
Dereference
ptr.* ��
const x:
Address Of &a All types const ptr = &
ptr.* ��
Name Syntax Types Remarks
Precedence
Arrays
test_arrays.zig
const expect = @import("std").testing.expect;
const assert = @import("std").debug.assert;
const mem = @import("std").mem;
�� array literal
const message = [_]u8{ 'h', 'e', 'l', 'l', 'o' };
comptime {
assert(mem.eql(u8, &message, &alt_message));
}
comptime {
assert(mem.eql(u8, &message, same_message));
}
�� modifiable array
var some_integers: [100]i32 = undefined;
comptime {
assert(all_zero.len �� 10);
assert(all_zero[5] �� 0);
}
Shell
$ zig test test_arrays.zig
1/4 test_arrays.test.iterate over an array���OK
2/4 test_arrays.test.modify an array���OK
3/4 test_arrays.test.compile-time array initialization���OK
4/4 test_arrays.test.array initialization with function calls���OK
All 4 tests passed.
See also:
• for
• Slices
Multidimensional Arrays
test_multidimensional_arrays.zig
const std = @import("std");
const expect = std.testing.expect;
const expectEqual = std.testing.expectEqual;
�� Access the 2D array by indexing the outer array, and then the inner a
try expect(mat4x5[3][4] �� 9.9);
Shell
$ zig test test_multidimensional_arrays.zig
1/1 test_multidimensional_arrays.test.multidimensional arrays���OK
All 1 tests passed.
Sentinel-Terminated Arrays
The syntax [N:x]T describes an array which has a sentinel element of value x at the index
corresponding to the length N .
test_null_terminated_array.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_null_terminated_array.zig
1/2 test_null_terminated_array.test.0-terminated sentinel array���OK
2/2 test_null_terminated_array.test.extra 0s in 0-terminated sentinel array�
All 2 tests passed.
See also:
• Sentinel-Terminated Pointers
• Sentinel-Terminated Slices
Destructuring Arrays
Shell
$ zig build-exe destructuring_arrays.zig
$ ./destructuring_arrays
x = 1, y = 2
{ 0, 165, 255, 255 }
See also:
• Destructuring
• Destructuring Tuples
• Destructuring Vectors
Vectors
A vector is a group of booleans, Integers, Floats, or Pointers which are operated on in parallel, using
SIMD instructions if possible. Vector types are created with the builtin function @Vector.
Vectors generally support the same builtin operators as their underlying base types. The only exception
to this is the keywords `and` and `or` on vectors of bools, since these operators affect control flow,
which is not allowed for vectors. All other operations are performed element-wise, and return a vector
of the same length as the input vectors. This includes:
For rearranging elements within and between vectors, Zig provides the @shuffle and @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.
test_vector.zig
const std = @import("std");
const expectEqual = std.testing.expectEqual;
�� You can also assign from a slice with comptime-known length to a vect
const vec2: @Vector(2, f32) = arr1[1��3].*;
Shell
$ zig test test_vector.zig
1/2 test_vector.test.Basic vector usage���OK
2/2 test_vector.test.Conversion between vectors, arrays, and slices���OK
All 2 tests passed.
See also:
• @splat
• @shuffle
• @select
• @reduce
Destructuring Vectors
destructuring_vectors.zig
const print = @import("std").debug.print;
�� emulate punpckldq
pub fn unpack(x: @Vector(4, f32), y: @Vector(4, f32)) @Vector(4, f32) {
const a, const c, _, _ = x;
const b, const d, _, _ = y;
return .{ a, b, c, d };
}
Shell
$ zig build-exe destructuring_vectors.zig
$ ./destructuring_vectors
{ 1, 5, 2, 6 }
See also:
• Destructuring
• Destructuring Tuples
• Destructuring Arrays
Pointers
Zig has two kinds of pointers: single-item and many-item.
• []T - is a slice (a fat pointer, which contains a pointer of type [*]T and a length).
◦ Supports index syntax: slice[i]
◦ Supports slice syntax: slice[start��end]
◦ Supports len property: slice.len
test_single_item_pointer.zig
const expect = @import("std").testing.expect;
�� Dereference a pointer:
try expect(x_ptr.* �� 1234);
�� When you get the address of a const variable, you get a const single-
try expect(@TypeOf(x_ptr) �� *const i32);
Shell
$ zig test test_single_item_pointer.zig
1/3 test_single_item_pointer.test.address of syntax���OK
2/3 test_single_item_pointer.test.pointer array access���OK
3/3 test_single_item_pointer.test.slice syntax���OK
All 3 tests passed.
Zig supports pointer arithmetic. It's better to assign the pointer to [*]T and increment that variable.
For example, directly incrementing the pointer from a slice will corrupt it.
test_pointer_arithmetic.zig
const expect = @import("std").testing.expect;
slice.ptr += 1;
�� now the slice is in an bad state since len has not been updated
Shell
$ zig test test_pointer_arithmetic.zig
1/2 test_pointer_arithmetic.test.pointer arithmetic with many-item pointer��
2/2 test_pointer_arithmetic.test.pointer arithmetic with slices���OK
All 2 tests passed.
In Zig, we generally prefer Slices rather than Sentinel-Terminated Pointers. You can turn an array or
pointer into a slice using slice syntax.
Slices have bounds checking and are therefore protected against this kind of Illegal Behavior. This is
one reason we prefer slices to pointers.
test_slice_bounds.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_slice_bounds.zig
1/1 test_slice_bounds.test.pointer slicing���OK
All 1 tests passed.
Pointers work at compile-time too, as long as the code does not depend on an undefined memory
layout:
test_comptime_pointers.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_comptime_pointers.zig
1/1 test_comptime_pointers.test.comptime pointers���OK
All 1 tests passed.
To convert an integer address into a pointer, use @ptrFromInt . To convert a pointer to an integer,
use @intFromPtr :
test_integer_pointer_conversion.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_integer_pointer_conversion.zig
1/1 test_integer_pointer_conversion.test.@intFromPtr and @ptrFromInt���OK
All 1 tests passed.
Zig is able to preserve memory addresses in comptime code, as long as the pointer is never
dereferenced:
test_comptime_pointer_conversion.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_comptime_pointer_conversion.zig
1/1 test_comptime_pointer_conversion.test.comptime @ptrFromInt���OK
All 1 tests passed.
@ptrCast converts a pointer's element type to another. This creates a new pointer that can cause
undetectable Illegal Behavior depending on the loads and stores that pass through it. Generally, other
kinds of type conversions are preferable to @ptrCast if possible.
test_pointer_casting.zig
const std = @import("std");
const expect = std.testing.expect;
�� Even this example is contrived - there are better ways to do the abov
�� pointer casting. For example, using a slice narrowing cast:
const u32_value = std.mem.bytesAsSlice(u32, bytes[0��])[0];
try expect(u32_value �� 0x12121212);
Shell
$ zig test test_pointer_casting.zig
1/2 test_pointer_casting.test.pointer casting���OK
2/2 test_pointer_casting.test.pointer child type���OK
All 2 tests passed.
See also:
• Optional Pointers
• @ptrFromInt
• @intFromPtr
• C Pointers
volatile
Loads and stores are assumed to not have side effects. If a given load or store should have side effects,
such as Memory Mapped Input/Output (MMIO), use volatile . In the following code, loads and
stores with mmio_ptr are guaranteed to all happen and in the same order as in source code:
test_volatile.zig
const expect = @import("std").testing.expect;
test "volatile" {
const mmio_ptr: *volatile u8 = @ptrFromInt(0x12345678);
try expect(@TypeOf(mmio_ptr) �� *volatile u8);
}
Shell
$ zig test test_volatile.zig
1/1 test_volatile.test.volatile���OK
All 1 tests passed.
Note that volatile is unrelated to concurrency and Atomics. If you see code that is using
volatile for something other than Memory Mapped Input/Output, it is probably a bug.
Alignment
Each type has an alignment - a number of bytes such that, when a value of the type is loaded from or
stored to memory, the memory address must be evenly divisible by this number. You can use @alignOf
to find out this value for any type.
Alignment depends on the CPU architecture, but is always a power of two, and less than 1 �� 29 .
In Zig, a pointer type has an alignment value. If the value is equal to the alignment of the underlying
type, it can be omitted from the type:
test_variable_alignment.zig
const std = @import("std");
const builtin = @import("builtin");
const expect = std.testing.expect;
Shell
$ zig test test_variable_alignment.zig
1/1 test_variable_alignment.test.variable alignment���OK
All 1 tests passed.
In the same way that a *i32 can be coerced to a *const i32 , a pointer with a larger alignment
can be implicitly cast to a pointer with a smaller alignment, but not vice versa.
You can specify alignment on variables and functions. If you do this, then pointers to them get the
specified alignment:
test_variable_func_alignment.zig
const expect = @import("std").testing.expect;
noop1();
try expect(@TypeOf(noop1) �� fn () void);
try expect(@TypeOf(&noop1) �� *align(1) const fn () void);
noop4();
try expect(@TypeOf(noop4) �� fn () void);
try expect(@TypeOf(&noop4) �� *align(4) const fn () void);
}
Shell
$ zig test test_variable_func_alignment.zig
1/2 test_variable_func_alignment.test.global variable alignment���OK
2/2 test_variable_func_alignment.test.function alignment���OK
All 2 tests passed.
If you have a pointer or a slice that has a small alignment, but you know that it actually has a bigger
alignment, use @alignCast to change the pointer into a more aligned pointer. This is a no-op at runtime,
but inserts a safety check:
test_incorrect_pointer_alignment.zig
const std = @import("std");
Shell
$ zig test test_incorrect_pointer_alignment.zig
1/1 test_incorrect_pointer_alignment.test.pointer alignment safety���thread
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_incorrect_p
const int_slice = std.mem.bytesAsSlice(u32, @as([]align(4) u8, @alignCas
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_incorrect_p
try std.testing.expect(foo(bytes) �� 0x11111111);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/a7ace22193
allowzero
This pointer attribute allows a pointer to have address zero. This is only ever needed on the
freestanding OS target, where the address zero is mappable. If you want to represent null pointers, use
Optional Pointers instead. Optional Pointers with allowzero are not the same size as pointers. In
this code example, if the pointer did not have the allowzero attribute, this would be a Pointer Cast
Invalid Null panic:
test_allowzero.zig
const std = @import("std");
const expect = std.testing.expect;
test "allowzero" {
var zero: usize = 0; �� var to make to runtime-known
_ = &zero; �� suppress 'var is never mutated' error
const ptr: *allowzero i32 = @ptrFromInt(zero);
try expect(@intFromPtr(ptr) �� 0);
}
Shell
$ zig test test_allowzero.zig
1/1 test_allowzero.test.allowzero���OK
All 1 tests passed.
Sentinel-Terminated Pointers
The syntax [*:x]T describes a pointer that has a length determined by a sentinel value. This
provides protection against buffer overflow and overreads.
sentinel-terminated_pointer.zig
const std = @import("std");
Shell
$ zig build-exe sentinel-terminated_pointer.zig -lc
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/sentinel-termina
_ = printf(&non_null_terminated_msg);
^~~~~~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/sentinel-termina
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/sentinel-termina
pub extern "c" fn printf(format: [*:0]const u8, ���) c_int;
^~~~~~~~~~~~~
referenced by:
callMain [inlined]: /home/ci/actions-runner/_work/zig-bootstrap/out/host
callMainWithArgs [inlined]: /home/ci/actions-runner/_work/zig-bootstrap/
main: /home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/s
1 reference(s) hidden; use '-freference-trace=4' to see all references
See also:
• Sentinel-Terminated Slices
• Sentinel-Terminated Arrays
Slices
A slice is a pointer and a length. The difference between an array and a slice is that the array's length is
part of the type and known at compile-time, whereas the slice's length is known at runtime. Both can
be accessed with the len field.
test_basic_slices.zig
const expect = @import("std").testing.expect;
const expectEqualSlices = @import("std").testing.expectEqualSlices;
�� If you slice with comptime-known start and end positions, the result
�� a pointer to an array, rather than a slice.
const array_ptr = array[0��array.len];
try expect(@TypeOf(array_ptr) �� *[array.len]i32);
�� Slices have array bounds checking. If you try to access something out
�� of bounds, you'll get a safety check failure:
slice[10] += 1;
�� Note that `slice.ptr` does not invoke safety checking, while `&slice[
�� asserts that the slice has len > 0.
Shell
$ zig test test_basic_slices.zig
1/1 test_basic_slices.test.basic slices���thread 3654886 panic: index out of
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_basic_slice
slice[10] += 1;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/a3970ea565
test_slices.zig
const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;
const fmt = std.fmt;
�� Generally, you can use UTF-8 and not worry about whether something is
�� string. If you don't need to deal with individual characters, no need
�� to decode.
try expect(mem.eql(u8, hello_world, "hello 世界"));
}
Shell
$ zig test test_slices.zig
1/2 test_slices.test.using slices for strings���OK
2/2 test_slices.test.slice pointer���OK
All 2 tests passed.
See also:
• Pointers
• for
• Arrays
Sentinel-Terminated Slices
The syntax [:x]T is a slice which has a runtime-known length and also guarantees a sentinel value
at the element indexed by the length. The type does not guarantee that there are no sentinel elements
before that. Sentinel-terminated slices allow element access to the len index.
test_null_terminated_slice.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_null_terminated_slice.zig
1/1 test_null_terminated_slice.test.0-terminated slice���OK
All 1 tests passed.
Sentinel-terminated slices can also be created using a variation of the slice syntax
data[start��end :x] , where data is a many-item pointer, array or slice and x is the
sentinel value.
test_null_terminated_slicing.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_null_terminated_slicing.zig
1/1 test_null_terminated_slicing.test.0-terminated slicing���OK
All 1 tests passed.
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-checked Illegal Behavior results.
test_sentinel_mismatch.zig
const std = @import("std");
const expect = std.testing.expect;
_ = slice;
}
Shell
$ zig test test_sentinel_mismatch.zig
1/1 test_sentinel_mismatch.test.sentinel mismatch���thread 3656691 panic: se
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_sentinel_mi
const slice = array[0��runtime_length :0];
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/b389536240
See also:
• Sentinel-Terminated Pointers
• Sentinel-Terminated Arrays
struct
test_structs.zig
�� Declare a struct.
�� Zig gives no guarantees about the order of fields and the size of
�� the struct but the fields are guaranteed to be ABI-aligned.
const Point = struct {
x: f32,
y: f32,
};
�� Other than being available to call with dot syntax, struct methods ar
�� not special. You can reference them as any other declaration inside
�� the struct:
try expect(Vec3.dot(v1, v2) �� 0.0);
}
_ = does_nothing;
}
first: ?*Node,
last: ?*Node,
len: usize,
};
}
�� Since types are first class values you can instantiate the type
�� by assigning it to a variable:
const ListOfInts = LinkedList(i32);
try expect(ListOfInts �� LinkedList(i32));
Shell
$ zig test test_structs.zig
1/4 test_structs.test.dot product���OK
2/4 test_structs.test.struct namespaced variable���OK
3/4 test_structs.test.field parent pointer���OK
4/4 test_structs.test.linked list���OK
All 4 tests passed.
Each struct field may have an expression indicating the default field value. Such expressions are
executed at comptime, and allow the field to be omitted in a struct literal expression:
struct_default_field_values.zig
const Foo = struct {
a: i32 = 1234,
b: i32,
};
Shell
$ zig test struct_default_field_values.zig
1/1 struct_default_field_values.test.default struct initialization fields���
All 1 tests passed.
Faulty Default Field Values
Default field values are only appropriate when the data invariants of a struct cannot be violated by
omitting that field from an initialization.
bad_default_value.zig
const Threshold = struct {
minimum: f32 = 0.25,
maximum: f32 = 0.75,
Shell
$ zig build-exe bad_default_value.zig
$ ./bad_default_value
thread 3656884 panic: reached unreachable code
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/debug.zig:5
if (!ok) unreachable; �� assertion failure
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/bad_default_valu
assert(t.maximum �� t.minimum);
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/bad_default_valu
const category = threshold.categorize(0.90);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
const result = root.main() catch |err| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
Above you can see the danger of ignoring this principle. The default field values caused the data
invariant to be violated, causing illegal behavior.
To fix this, remove the default values from all the struct fields, and provide a named default value:
struct_default_value.zig
const Threshold = struct {
minimum: f32,
maximum: f32,
If a struct value requires a runtime-known value in order to be initialized without violating data
invariants, then use an initialization method that accepts those runtime values, and populates the
remaining fields.
extern struct
An extern struct has in-memory layout matching the C ABI for the target.
If well-defined in-memory layout is not required, struct is a better choice because it places fewer
restrictions on the compiler.
See packed struct for a struct that has the ABI of its backing integer, which can be useful for modeling
flags.
See also:
• extern union
• extern enum
packed struct
packed structs, like enum , are based on the concept of interpreting integers differently. All packed
structs have a backing integer, which is implicitly determined by the total bit count of fields, or
explicitly specified. Packed structs have well-defined memory layout - exactly the same ABI as their
backing integer.
Each field of a packed struct is interpreted as a logical sequence of bits, arranged from least to most
significant. Allowed field types:
• An integer field uses exactly as many bits as its bit width. For example, a u5 will use 5 bits of
the backing integer.
• A bool field uses exactly 1 bit.
• An enum field uses exactly the bit width of its integer tag type.
• A packed union field uses exactly the bit width of the union field with the largest bit width.
• A packed struct field uses the bits of its backing integer.
This means that a packed struct can participate in a @bitCast or a @ptrCast to reinterpret
memory. This even works at comptime:
test_packed_structs.zig
const std = @import("std");
const native_endian = @import("builtin").target.cpu.arch.endian();
const expect = std.testing.expect;
fn doTheTest() !void {
try expect(@sizeOf(Full) �� 2);
try expect(@sizeOf(Divided) �� 2);
const full = Full{ .number = 0x1234 };
const divided: Divided = @bitCast(full);
try expect(divided.half1 �� 0x34);
try expect(divided.quarter3 �� 0x2);
try expect(divided.quarter4 �� 0x1);
const ordered: [2]u8 = @bitCast(full);
switch (native_endian) {
.big �� {
try expect(ordered[0] �� 0x12);
try expect(ordered[1] �� 0x34);
},
.little �� {
try expect(ordered[0] �� 0x34);
try expect(ordered[1] �� 0x12);
},
}
}
Shell
$ zig test test_packed_structs.zig
1/1 test_packed_structs.test.@bitCast between packed structs���OK
All 1 tests passed.
The backing integer can be inferred or explicitly provided. When inferred, it will be unsigned. When
explicitly provided, its bit width will be enforced at compile time to exactly match the total bit width of
the fields:
test_missized_packed_struct.zig
test "missized packed struct" {
const S = packed struct(u32) { a: u16, b: u8 };
_ = S{ .a = 4, .b = 2 };
}
Shell
$ zig test test_missized_packed_struct.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_missized_pa
const S = packed struct(u32) { a: u16, b: u8 };
^��
referenced by:
test.missized packed struct: /home/ci/actions-runner/_work/zig-bootstrap
test_pointer_to_non-byte_aligned_field.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_pointer_to_non-byte_aligned_field.zig
1/1 test_pointer_to_non-byte_aligned_field.test.pointer to non-byte-aligned
All 1 tests passed.
However, the pointer to a non-byte-aligned field has special properties and cannot be passed when a
normal pointer is expected:
test_misaligned_pointer.zig
const std = @import("std");
const expect = std.testing.expect;
In this case, the function bar 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:
test_packed_struct_field_address.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_packed_struct_field_address.zig
1/1 test_packed_struct_field_address.test.pointers of sub-byte-aligned field
All 1 tests passed.
test_bitOffsetOf_offsetOf.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_bitOffsetOf_offsetOf.zig
1/1 test_bitOffsetOf_offsetOf.test.offsets of non-byte-aligned fields���OK
All 1 tests passed.
Packed structs have the same alignment as their backing integer, however, overaligned pointers to
packed structs can override this:
test_overaligned_packed_struct.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_overaligned_packed_struct.zig
1/1 test_overaligned_packed_struct.test.overaligned pointer to packed struct
All 1 tests passed.
test_aligned_struct_fields.zig
const std = @import("std");
const expectEqual = std.testing.expectEqual;
Shell
$ zig test test_aligned_struct_fields.zig
1/1 test_aligned_struct_fields.test.aligned struct fields���OK
All 1 tests passed.
Equating packed structs results in a comparison of the backing integer, and only works for the �� and
�� Operators.
test_packed_struct_equality.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_packed_struct_equality.zig
1/1 test_packed_struct_equality.test.packed struct equality���OK
All 1 tests passed.
Field access and assignment can be understood as shorthand for bitshifts on the backing integer.
These operations are not atomic, so beware using field access syntax when combined with memory-
mapped input-output (MMIO). Instead of field access on volatile Pointers, construct a fully-formed new
value first, then write that value to the volatile pointer.
packed_struct_mmio.zig
pub const GpioRegister = packed struct(u8) {
GPIO0: bool,
GPIO1: bool,
GPIO2: bool,
GPIO3: bool,
reserved: u4 = 0,
};
�� Instead, do this:
gpio.* = new_states;
}
Struct Naming
Since all structs are anonymous, Zig infers the type name based on a few rules.
• If the struct is in the initialization expression of a variable, it gets named after that variable.
• If the struct is in the return expression, it gets named after the function it is returning from,
with the parameter values serialized.
• Otherwise, the struct gets a name such as (filename.funcname��struct_ID) .
• 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.
struct_name.zig
const std = @import("std");
Shell
$ zig build-exe struct_name.zig
$ ./struct_name
variable: struct_name.main.Foo
anonymous: struct_name.main��struct_22789
function: struct_name.List(i32)
Zig allows omitting the struct type of a literal. When the result is coerced, the struct literal will directly
instantiate the result location, with no copy:
test_struct_result.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_struct_result.zig
1/1 test_struct_result.test.anonymous struct literal���OK
All 1 tests passed.
The struct type can be inferred. Here the result location does not include a type, and so Zig infers the
type:
test_anonymous_struct.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_anonymous_struct.zig
1/1 test_anonymous_struct.test.fully anonymous struct���OK
All 1 tests passed.
Tuples
Anonymous structs can be created without specifying field names, and are referred to as "tuples". An
empty tuple looks like .{} and can be seen in one of the Hello World examples.
The fields are implicitly named using numbers starting from 0. Because their names are integers, they
cannot be accessed with . syntax without also wrapping them in @"" . Names inside @"" are
always recognised as identifiers.
Like arrays, tuples have a .len field, can be indexed (provided the index is comptime-known) and work
with the ++ and ** operators. They can also be iterated over with inline for.
test_tuples.zig
const std = @import("std");
const expect = std.testing.expect;
test "tuple" {
const values = .{
@as(u32, 1234),
@as(f64, 12.34),
true,
"hi",
} �� .{false} ** 2;
try expect(values[0] �� 1234);
try expect(values[4] �� false);
inline for (values, 0��) |v, i| {
if (i �� 2) continue;
try expect(v);
}
try expect(values.len �� 6);
try expect(values.@"3"[0] �� 'h');
}
Shell
$ zig test test_tuples.zig
1/1 test_tuples.test.tuple���OK
All 1 tests passed.
Destructuring Tuples
destructuring_block.zig
const print = @import("std").debug.print;
Tuple destructuring is helpful for dealing with functions and built-ins that return multiple values as a
tuple:
destructuring_return_value.zig
const print = @import("std").debug.print;
Shell
$ zig build-exe destructuring_return_value.zig
$ ./destructuring_return_value
10 / 3 = 3
10 % 3 = 1
See also:
• Destructuring
• Destructuring Arrays
• Destructuring Vectors
See also:
• comptime
• @fieldParentPtr
enum
test_enums.zig
const expect = @import("std").testing.expect;
const mem = @import("std").mem;
�� Declare an enum.
const Type = enum {
ok,
not_ok,
};
Shell
$ zig test test_enums.zig
1/8 test_enums.test.enum ordinal value���OK
2/8 test_enums.test.set enum ordinal value���OK
3/8 test_enums.test.enum implicit ordinal values and overridden values���OK
4/8 test_enums.test.enum method���OK
5/8 test_enums.test.enum switch���OK
6/8 test_enums.test.std.meta.Tag���OK
7/8 test_enums.test.@typeInfo���OK
8/8 test_enums.test.@tagName���OK
All 8 tests passed.
See also:
• @typeInfo
• @tagName
• @sizeOf
extern enum
enum_export_error.zig
const Foo = enum { a, b, c };
export fn entry(foo: Foo) void {
_ = foo;
}
Shell
$ zig build-obj enum_export_error.zig -target x86_64-linux
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/enum_export_erro
export fn entry(foo: Foo) void {
^~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/enum_export_erro
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/enum_export_erro
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/enum_export_erro
const Foo = enum { a, b, c };
^~~~~~~~~~~~~~~~
referenced by:
root: /home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/s
comptime: /home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/s
2 reference(s) hidden; use '-freference-trace=4' to see all references
enum_export.zig
const Foo = enum(c_int) { a, b, c };
export fn entry(foo: Foo) void {
_ = foo;
}
Shell
$ zig build-obj enum_export.zig
Enum Literals
Enum literals allow specifying the name of an enum field without specifying the enum type:
test_enum_literals.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_enum_literals.zig
1/2 test_enum_literals.test.enum literals���OK
2/2 test_enum_literals.test.switch using enum literals���OK
All 2 tests passed.
Non-exhaustive enum
A non-exhaustive enum can be created by adding a trailing _ field. The enum must specify a tag type
and cannot consume every enumeration value.
@enumFromInt on a non-exhaustive enum involves the safety semantics of @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 else prong. With
a _ prong the compiler errors if all the known tag names are not handled by the switch.
test_switch_non-exhaustive.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_switch_non-exhaustive.zig
1/1 test_switch_non-exhaustive.test.switch on non-exhaustive enum���OK
All 1 tests passed.
union
A bare union defines a set of possible types that a value can be as a list of fields. Only one field can
be active at a time. The in-memory representation of bare unions is not guaranteed. Bare unions
cannot be used to reinterpret memory. For that, use @ptrCast, or use an extern union or a packed
union which have guaranteed in-memory layout. Accessing the non-active field is safety-checked
Illegal Behavior:
test_wrong_union_access.zig
const Payload = union {
int: i64,
float: f64,
boolean: bool,
};
test "simple union" {
var payload = Payload{ .int = 1234 };
payload.float = 12.34;
}
Shell
$ zig test test_wrong_union_access.zig
1/1 test_wrong_union_access.test.simple union���thread 3654666 panic: access
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_wrong_union
payload.float = 12.34;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/719a037f70
test_simple_union.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_simple_union.zig
1/1 test_simple_union.test.simple union���OK
All 1 tests passed.
Tagged union
Unions can be declared with an enum tag type. This turns the union into a tagged union, which makes it
eligible to use with switch expressions. Tagged unions coerce to their tag type: Type Coercion: Unions
and Enums.
test_tagged_union.zig
const std = @import("std");
const expect = std.testing.expect;
switch (c) {
.ok �� |value| try expect(value �� 42),
.not_ok �� unreachable,
}
}
Shell
$ zig test test_tagged_union.zig
1/2 test_tagged_union.test.switch on tagged union���OK
2/2 test_tagged_union.test.get tag type���OK
All 2 tests passed.
In order to modify the payload of a tagged union in a switch expression, place a * before the variable
name to make it a pointer:
test_switch_modify_tagged_union.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_switch_modify_tagged_union.zig
1/1 test_switch_modify_tagged_union.test.modify tagged union in switch���OK
All 1 tests passed.
Unions can be made to infer the enum tag type. Further, unions can have methods just like structs and
enums.
test_union_method.zig
const std = @import("std");
const expect = std.testing.expect;
try expect(v1.truthy());
try expect(!v2.truthy());
try expect(!v3.truthy());
}
Shell
$ zig test test_union_method.zig
1/1 test_union_method.test.union method���OK
All 1 tests passed.
@tagName can be used to return a comptime [:0]const u8 value representing the field name:
test_tagName.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_tagName.zig
1/1 test_tagName.test.@tagName���OK
All 1 tests passed.
extern union
An extern union has memory layout guaranteed to be compatible with the target C ABI.
See also:
• extern struct
packed union
A packed union has well-defined in-memory layout and is eligible to be in a packed struct.
Anonymous Struct Literals syntax can be used to initialize unions without specifying the type:
test_anonymous_union.zig
const std = @import("std");
const expect = std.testing.expect;
const Number = union {
int: i32,
float: f64,
};
fn makeNumber() Number {
return .{ .float = 12.34 };
}
Shell
$ zig test test_anonymous_union.zig
1/1 test_anonymous_union.test.anonymous union literal syntax���OK
All 1 tests passed.
opaque
opaque {} declares a new type with an unknown (but non-zero) size and alignment. It can contain
declarations the same as structs, unions, and enums.
This is typically used for type safety when interacting with C code that does not expose struct details.
Example:
test_opaque.zig
const Derp = opaque {};
const Wat = opaque {};
Shell
$ zig test test_opaque.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_opaque.zig:
bar(w);
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_opaque.zig:
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_opaque.zig:
const Wat = opaque {};
^~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_opaque.zig:
const Derp = opaque {};
^~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_opaque.zig:
extern fn bar(d: *Derp) void;
^~~~~
referenced by:
test.call foo: /home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langr
Blocks
Blocks are used to limit the scope of variable declarations:
test_blocks.zig
test "access variable after block scope" {
{
var x: i32 = 1;
_ = &x;
}
x += 1;
}
Shell
$ zig test test_blocks.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_blocks.zig:
x += 1;
^
Blocks are expressions. When labeled, break can be used to return a value from the block:
test_labeled_break.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_labeled_break.zig
1/1 test_labeled_break.test.labeled break from labeled block expression���OK
All 1 tests passed.
See also:
• Labeled while
• Labeled for
Shadowing
Identifiers are never allowed to "hide" other identifiers by using the same name:
test_shadowing.zig
const pi = 3.14;
Shell
$ zig test test_shadowing.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_shadowing.z
var pi: i32 = 1234;
^~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_shadowing.z
const pi = 3.14;
^~~~~~~~~~~~~~~
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:
test_scopes.zig
test "separate scopes" {
{
const pi = 3.14;
_ = pi;
}
{
var pi: bool = true;
_ = π
}
}
Shell
$ zig test test_scopes.zig
1/1 test_scopes.test.separate scopes���OK
All 1 tests passed.
Empty Blocks
test_empty_block.zig
const std = @import("std");
const expect = std.testing.expect;
test {
const a = {};
const b = void{};
try expect(@TypeOf(a) �� void);
try expect(@TypeOf(b) �� void);
try expect(a �� b);
}
Shell
$ zig test test_empty_block.zig
1/1 test_empty_block.test_0���OK
All 1 tests passed.
switch
test_switch.zig
const std = @import("std");
const builtin = @import("builtin");
const expect = std.testing.expect;
�� Ranges can be specified using the ��� syntax. These are inclusive
�� of both ends.
5���100 �� 1,
Shell
$ zig test test_switch.zig
1/2 test_switch.test.switch simple���OK
2/2 test_switch.test.switch inside function���OK
All 2 tests passed.
switch can be used to capture the field values of a Tagged union. Modifications to the field values
can be done by placing a * before the capture variable name, turning it into a pointer.
test_switch_tagged_union.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_switch_tagged_union.zig
1/1 test_switch_tagged_union.test.switch on tagged union���OK
All 1 tests passed.
See also:
• comptime
• enum
• @compileError
• Compile Variables
Exhaustive Switching
When a switch expression does not have an else clause, it must exhaustively list all the possible
values. Failure to do so is a compile error:
test_unhandled_enumeration_value.zig
const Color = enum {
auto,
off,
on,
};
Shell
$ zig test test_unhandled_enumeration_value.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unhandled_e
switch (color) {
^~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unhandled_e
off,
^��
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unhandled_e
const Color = enum {
^~~~
Enum Literals can be useful to use with switch to avoid repetitively specifying enum or union types:
test_exhaustive_switch.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_exhaustive_switch.zig
1/1 test_exhaustive_switch.test.enum literals with switch���OK
All 1 tests passed.
Labeled switch
When a switch statement is labeled, it can be referenced from a break or continue . break
will return a value from the switch .
A continue targeting a switch must have an operand. When executed, it will jump to the matching
prong, as if the switch were executed again with the continue 's operand replacing the initial
switch value.
test_switch_continue.zig
const std = @import("std");
continue :sw 1;
},
1 �� return,
else �� unreachable,
}
}
Shell
$ zig test test_switch_continue.zig
1/1 test_switch_continue.test.switch continue���OK
All 1 tests passed.
test_switch_continue_equivalent.zig
const std = @import("std");
sw = 1;
continue;
},
1 �� return,
else �� unreachable,
}
}
}
Shell
$ zig test test_switch_continue_equivalent.zig
1/1 test_switch_continue_equivalent.test.switch continue, equivalent loop���
All 1 tests passed.
This can improve clarity of (for example) state machines, where the syntax continue :sw
.next_state is unambiguous, explicit, and immediately understandable.
However, the motivating example is a switch on each element of an array, where using a single switch
can improve clarity and performance:
test_switch_dispatch_loop.zig
const std = @import("std");
const expectEqual = std.testing.expectEqual;
ip += 1;
continue :vm code[ip];
},
.mul �� {
try stack.append(stack.pop()�� * stack.pop()��);
ip += 1;
continue :vm code[ip];
},
.end �� stack.pop()��,
};
}
test "evaluate" {
const result = try evaluate(&.{ 7, 2, -3 }, &.{ .mul, .add, .end });
try expectEqual(1, result);
}
Shell
$ zig test test_switch_dispatch_loop.zig
1/1 test_switch_dispatch_loop.test.evaluate���OK
All 1 tests passed.
If the operand is runtime-known, each continue can embed a conditional branch inline (ideally
through a jump table), which allows a CPU to predict its target independently of any other prong. A
loop-based lowering would force every branch through the same dispatch point, hindering branch
prediction.
Switch prongs can be marked as inline to generate the prong's body for each possible value it
could have, making the captured value comptime.
test_inline_switch.zig
const std = @import("std");
const expect = std.testing.expect;
const expectError = std.testing.expectError;
Shell
$ zig test test_inline_switch.zig
1/1 test_inline_switch.test.using @typeInfo with runtime values���OK
All 1 tests passed.
inline_prong_range.zig
fn isFieldOptional(comptime T: type, field_index: usize) !bool {
const fields = @typeInfo(T).@"struct".fields;
return switch (field_index) {
inline 0���fields.len - 1 �� |idx| @typeInfo(fields[idx].type
else �� return error.IndexOutOfBounds,
};
}
inline else prongs can be used as a type safe alternative to inline for loops:
test_inline_else.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_inline_else.zig
1/1 test_inline_else.test.inline for and inline else similarity���OK
All 1 tests passed.
When using an inline prong switching on an union an additional capture can be used to obtain the
union's enum tag value.
test_inline_switch_union_tag.zig
const std = @import("std");
const expect = std.testing.expect;
const U = union(enum) {
a: u32,
b: f32,
};
fn getNum(u: U) u32 {
switch (u) {
�� Here `num` is a runtime-known value that is either
�� `u.a` or `u.b` and `tag` is `u`'s comptime-known tag value.
inline else �� |num, tag| {
if (tag �� .b) {
return @intFromFloat(num);
}
return num;
},
}
}
test "test" {
const u = U{ .b = 42 };
try expect(getNum(u) �� 42);
}
Shell
$ zig test test_inline_switch_union_tag.zig
1/1 test_inline_switch_union_tag.test.test���OK
All 1 tests passed.
See also:
• inline while
• inline for
while
A while loop is used to repeatedly execute an expression until some condition is no longer true.
test_while.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_while.zig
1/1 test_while.test.while basic���OK
All 1 tests passed.
test_while_break.zig
const expect = @import("std").testing.expect;
test_while_continue.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_while_continue.zig
1/1 test_while_continue.test.while continue���OK
All 1 tests passed.
While loops support a continue expression which is executed when the loop is continued. The
continue keyword respects this expression.
test_while_continue_expression.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_while_continue_expression.zig
1/2 test_while_continue_expression.test.while loop continue expression���OK
2/2 test_while_continue_expression.test.while loop continue expression, more
All 2 tests passed.
While loops are expressions. The result of the expression is the result of the else clause of a while
loop, which is executed when the condition of the while loop is tested as false.
break , like return , accepts a value parameter. This is the result of the while expression.
When you break from a while loop, the else branch is not evaluated.
test_while_else.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_while_else.zig
1/1 test_while_else.test.while else���OK
All 1 tests passed.
Labeled while
When a while loop is labeled, it can be referenced from a break or continue from within a
nested loop:
test_while_nested_break.zig
test "nested break" {
outer: while (true) {
while (true) {
break :outer;
}
}
}
Shell
$ zig test test_while_nested_break.zig
1/2 test_while_nested_break.test.nested break���OK
2/2 test_while_nested_break.test.nested continue���OK
All 2 tests passed.
Just like if expressions, while loops can take an optional as the condition and capture the payload.
When null is encountered the loop exits.
When the |x| syntax is present on a while expression, the while condition must have an Optional
Type.
The else branch is allowed on optional iteration. In this case, it will be executed on the first null
value encountered.
test_while_null_capture.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_while_null_capture.zig
1/1 test_while_null_capture.test.while null capture���OK
All 1 tests passed.
Just like if expressions, while loops can take an error union as the condition and capture the payload or
the error code. When the condition results in an error code the else branch is evaluated and the loop is
finished.
When the else |x| syntax is present on a while expression, the while condition must have an
Error Union Type.
test_while_error_capture.zig
const expect = @import("std").testing.expect;
fn eventuallyErrorSequence() anyerror!u32 {
return if (numbers_left �� 0) error.ReachedZero else blk: {
numbers_left -= 1;
break :blk numbers_left;
};
}
Shell
$ zig test test_while_error_capture.zig
1/1 test_while_error_capture.test.while error union capture���OK
All 1 tests passed.
inline while
While loops can be inlined. This causes the loop to be unrolled, which allows the code to do some
things which only work at compile time, such as use types as first class values.
test_inline_while.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_inline_while.zig
1/1 test_inline_while.test.inline while loop���OK
All 1 tests passed.
• You need the loop to execute at comptime for the semantics to work.
• You have a benchmark to prove that forcibly unrolling the loop in this way is measurably faster.
See also:
• if
• Optionals
• Errors
• comptime
• unreachable
for
test_for.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_for.zig
1/4 test_for.test.for basics���OK
2/4 test_for.test.multi object for���OK
3/4 test_for.test.for reference���OK
4/4 test_for.test.for else���OK
All 4 tests passed.
Labeled for
When a for loop is labeled, it can be referenced from a break or continue from within a
nested loop:
test_for_nested_break.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_for_nested_break.zig
1/2 test_for_nested_break.test.nested break���OK
2/2 test_for_nested_break.test.nested continue���OK
All 2 tests passed.
inline for
For loops can be inlined. This causes the loop to be unrolled, which allows the code to do some things
which only work at compile time, such as use types as first class values. The capture value and iterator
value of inlined for loops are compile-time known.
test_inline_for.zig
const expect = @import("std").testing.expect;
• You need the loop to execute at comptime for the semantics to work.
• You have a benchmark to prove that forcibly unrolling the loop in this way is measurably faster.
See also:
• while
• comptime
• Arrays
• Slices
if
test_if.zig
�� If expressions have three uses, corresponding to the three types:
�� * bool
�� * ?T
�� * anyerror!T
const a: anyerror!u32 = 0;
if (a) |value| {
try expect(value �� 0);
} else |err| {
_ = err;
unreachable;
}
if (c) |value| {
try expect(value �� 9);
} else |_| {
unreachable;
}
}
Shell
$ zig test test_if.zig
1/3 test_if.test.if expression���OK
2/3 test_if.test.if boolean���OK
3/3 test_if.test.if error union���OK
All 3 tests passed.
if with Optionals
test_if_optionals.zig
const expect = @import("std").testing.expect;
const a: ?u32 = 0;
if (a) |value| {
try expect(value �� 0);
} else {
unreachable;
}
if (c) |value| {
try expect(value �� 2);
} else {
unreachable;
}
}
const a: anyerror!?u32 = 0;
if (a) |optional_value| {
try expect(optional_value�� �� 0);
} else |err| {
_ = err;
unreachable;
}
if (d) |optional_value| {
try expect(optional_value�� �� 9);
} else |_| {
unreachable;
}
}
Shell
$ zig test test_if_optionals.zig
1/2 test_if_optionals.test.if optional���OK
2/2 test_if_optionals.test.if error union with optional���OK
All 2 tests passed.
See also:
• Optionals
• Errors
defer
Executes an expression unconditionally at scope exit.
test_defer.zig
const std = @import("std");
const expect = std.testing.expect;
const print = std.debug.print;
fn deferExample() !usize {
var a: usize = 1;
{
defer a = 2;
a = 1;
}
try expect(a �� 2);
a = 5;
return a;
}
Shell
$ zig test test_defer.zig
1/1 test_defer.test.defer basics���OK
All 1 tests passed.
defer {
print("1 ", .{});
}
defer {
print("2 ", .{});
}
if (false) {
�� defers are not run if they are never executed.
defer {
print("3 ", .{});
}
}
}
Shell
$ zig build-exe defer_unwind.zig
$ ./defer_unwind
2 1
test_invalid_defer.zig
fn deferInvalidExample() !void {
defer {
return error.DeferError;
}
return error.DeferError;
}
Shell
$ zig test test_invalid_defer.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_invalid_def
return error.DeferError;
^~~~~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_invalid_def
defer {
^~~~~
See also:
• Errors
unreachable
In Debug and ReleaseSafe mode unreachable emits a call to panic with the message
reached unreachable code .
In ReleaseFast and ReleaseSmall mode, the optimizer uses the assumption that unreachable
code will never be hit to perform optimizations.
Basics
test_unreachable.zig
�� unreachable is used to assert that control flow will never reach a
�� particular location:
test "basic math" {
const x = 1;
const y = 2;
if (x + y �� 3) {
unreachable;
}
}
Shell
$ zig test test_unreachable.zig
1/1 test_unreachable.test.basic math���OK
All 1 tests passed.
test_assertion_failure.zig
�� This is how std.debug.assert is implemented
fn assert(ok: bool) void {
if (!ok) unreachable; �� assertion failure
}
Shell
$ zig test test_assertion_failure.zig
1/1 test_assertion_failure.test.this will fail���thread 3656376 panic: reach
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_assertion_f
if (!ok) unreachable; �� assertion failure
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_assertion_f
assert(false);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/75db5b5f55
At Compile-Time
test_comptime_unreachable.zig
const assert = @import("std").debug.assert;
Shell
$ zig test test_comptime_unreachable.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_un
assert(@TypeOf(unreachable) �� noreturn);
^~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_un
assert(@TypeOf(unreachable) �� noreturn);
^~~~~~~~~~~
See also:
• Zig Test
• Build Mode
• comptime
noreturn
noreturn is the type of:
• break
• continue
• return
• unreachable
• while (true) {}
When resolving types together, such as if clauses or switch prongs, the noreturn type is
compatible with every other type. Consider:
test_noreturn.zig
fn foo(condition: bool, b: u32) void {
const a = if (condition) b else return;
_ = a;
@panic("do something with a");
}
test "noreturn" {
foo(false, 1);
}
Shell
$ zig test test_noreturn.zig
1/1 test_noreturn.test.noreturn���OK
All 1 tests passed.
test_noreturn_from_exit.zig
const std = @import("std");
const builtin = @import("builtin");
const native_arch = builtin.cpu.arch;
const expect = std.testing.expect;
test "foo" {
const value = bar() catch ExitProcess(1);
try expect(value �� 1234);
}
fn bar() anyerror!u32 {
return 1234;
}
Shell
$ zig test test_noreturn_from_exit.zig -target x86_64-windows ��test-no-exec
Functions
test_functions.zig
const std = @import("std");
const builtin = @import("builtin");
const native_arch = builtin.cpu.arch;
const expect = std.testing.expect;
return a + b;
}
�� The export specifier makes a function externally visible in the generated
�� object file, and makes it use the C ABI.
export fn sub(a: i8, b: i8) i8 {
return a - b;
}
�� The @branchHint builtin can be used to tell the optimizer that a function
fn abort() noreturn {
@branchHint(.cold);
while (true) {}
}
�� The naked calling convention makes a function not have any function prolo
�� This can be useful when integrating with assembly.
fn _start() callconv(.naked) noreturn {
abort();
}
test "function" {
try expect(doOp(add, 5, 6) �� 11);
try expect(doOp(sub2, 5, 6) �� -1);
}
Shell
$ zig test test_functions.zig
1/1 test_functions.test.function���OK
All 1 tests passed.
There is a difference between a function body and a function pointer. Function bodies are comptime-
only types while function Pointers may be runtime-known.
Pass-by-value Parameters
Primitive types such as Integers and Floats passed as parameters are copied, and then the copy is
available in the function body. This is called "passing by value". Copying a primitive type is essentially
free and typically involves nothing more than setting a register.
Structs, unions, and arrays can sometimes be more efficiently passed as a reference, since a copy
could be arbitrarily expensive depending on the size. When these types are passed as parameters, Zig
may choose to copy and pass by value, or pass by reference, whichever way Zig decides will be faster.
This is made possible, in part, by the fact that parameters are immutable.
test_pass_by_reference_or_value.zig
const Point = struct {
x: i32,
y: i32,
};
Shell
$ zig test test_pass_by_reference_or_value.zig
1/1 test_pass_by_reference_or_value.test.pass struct to function���OK
All 1 tests passed.
For extern functions, Zig follows the C ABI for passing structs and unions by value.
Function parameters can be declared with anytype in place of the type. In this case the parameter
types will be inferred when the function is called. Use @TypeOf and @typeInfo to get information about
the inferred type.
test_fn_type_inference.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_fn_type_inference.zig
1/1 test_fn_type_inference.test.fn type inference���OK
All 1 tests passed.
inline fn
Adding the inline keyword to a function definition makes that function become semantically
inlined at the callsite. This is not a hint to be possibly observed by optimization passes, but has
implications on the types and values involved in the function call.
Unlike normal function calls, arguments at an inline function callsite which are compile-time known are
treated as Compile Time Parameters. This can potentially propagate all the way to the return value:
inline_call.zig
const std = @import("std");
Shell
$ zig build-exe inline_call.zig
$ ./inline_call
runtime a = 1200 b = 34
If inline is removed, the test fails with the compile error instead of passing.
It is generally better to let the compiler decide when to inline a function, except for these scenarios:
• To change how many stack frames are in the call stack, for debugging purposes.
• To force comptime-ness of the arguments to propagate to the return value of the function, as in
the above example.
• Real world performance measurements demand it.
Note that inline actually restricts what the compiler is allowed to do. This can harm binary size,
compilation speed, and even runtime performance.
Function Reflection
test_fn_reflection.zig
const std = @import("std");
const math = std.math;
const testing = std.testing;
try testing.expect(@typeInfo(@TypeOf(math.Log2Int)).@"fn".is_generic);
}
Shell
$ zig test test_fn_reflection.zig
1/1 test_fn_reflection.test.fn reflection���OK
All 1 tests passed.
Errors
Error Set Type
An error set is like an enum. However, each error name across the entire compilation gets assigned an
unsigned integer greater than 0. You are allowed to declare the same error name more than once, and
if you do, it gets assigned the same integer value.
The error set type defaults to a u16 , though if the maximum number of distinct error values is
provided via the ��error-limit [num] command line parameter an integer type with the
minimum number of bits required to represent all of the error values will be used.
test_coerce_error_subset_to_superset.zig
const std = @import("std");
Shell
$ zig test test_coerce_error_subset_to_superset.zig
1/1 test_coerce_error_subset_to_superset.test.coerce subset to superset���OK
All 1 tests passed.
test_coerce_error_superset_to_subset.zig
const FileOpenError = error{
AccessDenied,
OutOfMemory,
FileNotFound,
};
Shell
$ zig test test_coerce_error_superset_to_subset.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_coerce_erro
return err;
^��
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_coerce_erro
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_coerce_erro
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_coerce_erro
fn foo(err: FileOpenError) AllocationError {
^~~~~~~~~~~~~~~
referenced by:
test.coerce superset to subset: /home/ci/actions-runner/_work/zig-bootst
There is a shortcut for declaring an error set with only 1 value, and then getting that value:
single_value_error_set_shortcut.zig
const err = error.FileNotFound;
single_value_error_set.zig
const err = (error{FileNotFound}).FileNotFound;
anyerror refers to the global error set. This is the error set that contains all errors in the entire
compilation unit, i.e. it is the union of all other error sets.
You can coerce any error set to the global one, and you can explicitly cast an error of the global error
set to a non-global one. This inserts a language-level assert to make sure the error value is in fact in
the destination error set.
The global error set should generally be avoided because it prevents the compiler from knowing what
errors are possible at compile-time. Knowing the error set at compile-time is better for generated
documentation and helpful error messages, such as forgetting a possible error value in a switch.
An error set type and normal type can be combined with the ! binary operator to form an error union
type. You are likely to use an error union type more often than an error set type by itself.
error_union_parsing_u64.zig
const std = @import("std");
const maxInt = std.math.maxInt;
if (digit �� radix) {
return error.InvalidChar;
}
�� x *= radix
var ov = @mulWithOverflow(x, radix);
if (ov[1] �� 0) return error.OverFlow;
�� x += digit
ov = @addWithOverflow(ov[0], digit);
if (ov[1] �� 0) return error.OverFlow;
x = ov[0];
}
return x;
}
fn charToDigit(c: u8) u8 {
return switch (c) {
'0'���'9' �� c - '0',
'A'���'Z' �� c - 'A' + 10,
'a'���'z' �� c - 'a' + 10,
else �� maxInt(u8),
};
}
Shell
$ zig test error_union_parsing_u64.zig
1/1 error_union_parsing_u64.test.parse u64���OK
All 1 tests passed.
Notice the return type is !u64 . This means that the function either returns an unsigned 64 bit
integer, or an error. We left off the error set to the left of the ! , so the error set is inferred.
Within the function definition, you can see some return statements that return an error, and at the
bottom a return statement that returns a u64 . Both types coerce to anyerror!u64 .
What it looks like to use this function varies depending on what you're trying to do. One of the
following:
catch
If you want to provide a default value, you can use the catch binary operator:
catch.zig
const parseU64 = @import("error_union_parsing_u64.zig").parseU64;
In this code, number will be equal to the successfully parsed string, or a default value of 13. The
type of the right hand side of the binary catch operator must match the unwrapped error union
type, or be of type noreturn .
If you want to provide a default value with catch after performing some logic, you can combine
catch with named Blocks:
handle_error_with_catch_block.zig.zig
const parseU64 = @import("error_union_parsing_u64.zig").parseU64;
try
Let's say you wanted to return the error if you got one, otherwise continue with the function logic:
catch_err_return.zig
const parseU64 = @import("error_union_parsing_u64.zig").parseU64;
try.zig
const parseU64 = @import("error_union_parsing_u64.zig").parseU64;
try evaluates an error union expression. If it is an error, it returns from the current function with the
same error. Otherwise, the expression results in the unwrapped value.
Maybe you know with complete certainty that an expression will never be an error. In this case you can
do this:
Here we know for sure that "1234" will parse successfully. So we put the unreachable value on
the right hand side. unreachable invokes safety-checked Illegal Behavior, so in Debug and
ReleaseSafe, triggers a safety panic by default. So, while we're debugging the application, if there was
a surprise error here, the application would crash appropriately.
You may want to take a different action for every situation. For that, we combine the if and switch
expression:
handle_all_error_scenarios.zig
fn doAThing(str: []u8) void {
if (parseU64(str, 10)) |number| {
doSomethingWithNumber(number);
} else |err| switch (err) {
error.Overflow �� {
�� handle overflow���
},
�� we promise that InvalidChar won't happen (or crash in debug mode
error.InvalidChar �� unreachable,
}
}
Finally, you may want to handle only some errors. For that, you can capture the unhandled errors in the
else case, which now contains a narrower error set:
handle_some_error_scenarios.zig
fn doAnotherThing(str: []u8) error{InvalidChar}!void {
if (parseU64(str, 10)) |number| {
doSomethingWithNumber(number);
} else |err| switch (err) {
error.Overflow �� {
�� handle overflow���
},
else �� |leftover_err| return leftover_err,
}
}
You must use the variable capture syntax. If you don't need the variable, you can capture with _ and
avoid the switch .
handle_no_error_scenarios.zig
fn doADifferentThing(str: []u8) void {
if (parseU64(str, 10)) |number| {
doSomethingWithNumber(number);
} else |_| {
�� do as you'd like
}
}
errdefer
The other component to error handling is defer statements. In addition to an unconditional defer, Zig
has errdefer , which evaluates the deferred expression on block exit path if and only if the function
returned with an error from the block.
Example:
errdefer_example.zig
fn createFoo(param: i32) !Foo {
const foo = try tryToAllocateFoo();
�� now we have allocated foo. we need to free it if the function fails.
�� but we want to return it if the function succeeds.
errdefer deallocateFoo(foo);
�� here the errdefer will not run since we're returning success from the
�� but the defer will run!
return foo;
}
The neat thing about this is that you get robust error handling without the verbosity and cognitive
overhead of trying to make sure every exit path is covered. The deallocation code is always directly
following the allocation code.
test_errdefer_capture.zig
const std = @import("std");
Shell
$ zig test test_errdefer_capture.zig
1/1 test_errdefer_capture.test.errdefer capture���OK
All 1 tests passed.
• These primitives give enough expressiveness that it's completely practical to have failing to
check for an error be a compile error. If you really want to ignore the error, you can add catch
unreachable and get the added benefit of crashing in Debug and ReleaseSafe modes if your
assumption was wrong.
• Since Zig understands error types, it can pre-weight branches in favor of errors not occurring.
Just a small optimization benefit that is not available in other languages.
See also:
• defer
• if
• switch
An error union is created with the ! binary operator. You can use compile-time reflection to access
the child type of an error union:
test_error_union.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_error_union.zig
1/1 test_error_union.test.error union���OK
All 1 tests passed.
Use the �� operator to merge two error sets together. The resulting error set contains the errors of
both error sets. Doc comments from the left-hand side override doc comments from the right-hand
side. In this example, the doc comments for C.PathNotFound is A doc comment .
This is especially useful for functions which return different error sets depending on comptime
branches. For example, the Zig standard library uses LinuxFileOpenError ��
WindowsFileOpenError for the error set of opening files.
test_merging_error_sets.zig
const A = error{
NotDir,
const C = A �� B;
fn foo() C!void {
return error.NotDir;
}
Shell
$ zig test test_merging_error_sets.zig
1/1 test_merging_error_sets.test.merge error sets���OK
All 1 tests passed.
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 ! operator to the function’s return type, like !T :
test_inferred_error_sets.zig
�� With an inferred error set
pub fn add_inferred(comptime T: type, a: T, b: T) !T {
const ov = @addWithOverflow(a, b);
if (ov[1] �� 0) return error.Overflow;
return ov[0];
}
Shell
$ zig test test_inferred_error_sets.zig
1/1 test_inferred_error_sets.test.inferred error set���OK
All 1 tests passed.
When a function has an inferred error set, that function becomes generic and thus it becomes trickier
to do certain things with it, such as obtain a function pointer, or have an error set that is consistent
across different build targets. Additionally, inferred error sets are incompatible with recursion.
In these situations, it is recommended to use an explicit error set. You can generally start with an
empty error set and let compile errors guide you toward completing the set.
Error Return Traces show all the points in the code that an error was returned to the calling function.
This makes it practical to use try everywhere and then still be able to know what happened if an error
ends up bubbling all the way out of your application.
error_return_trace.zig
pub fn main() !void {
try foo(12);
}
fn foo(x: i32) !void {
if (x �� 5) {
try bar();
} else {
try bang2();
}
}
fn bar() !void {
if (baz()) {
try quux();
} else |err| switch (err) {
error.FileNotFound �� try hello(),
}
}
fn baz() !void {
try bang1();
}
fn quux() !void {
try bang2();
}
fn hello() !void {
try bang2();
}
fn bang1() !void {
return error.FileNotFound;
}
fn bang2() !void {
return error.PermissionDenied;
}
Shell
$ zig build-exe error_return_trace.zig
$ ./error_return_trace
error: PermissionDenied
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
return error.FileNotFound;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
try bang1();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
return error.PermissionDenied;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
try bang2();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
error.FileNotFound �� try hello(),
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
try bar();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/error_return_tra
try foo(12);
^
You can see that the final error bubbled up was PermissionDenied , but the original error that
started this whole thing was FileNotFound . In the bar function, the code handles the original
error code, and then returns another one, from the switch statement. Error Return Traces make this
clear, whereas a stack trace would look like this:
stack_trace.zig
pub fn main() void {
foo(12);
}
fn bar() void {
if (baz()) {
quux();
} else {
hello();
}
}
fn baz() bool {
return bang1();
}
fn quux() void {
bang2();
}
fn hello() void {
bang2();
}
fn bang1() bool {
return false;
}
fn bang2() void {
@panic("PermissionDenied");
}
Shell
$ zig build-exe stack_trace.zig
$ ./stack_trace
thread 3652995 panic: PermissionDenied
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/stack_trace.zig:
@panic("PermissionDenied");
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/stack_trace.zig:
bang2();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/stack_trace.zig:
hello();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/stack_trace.zig:
bar();
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/stack_trace.zig:
foo(12);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
Here, the stack trace does not explain how the control flow in bar got to the hello() call. One
would have to open a debugger or further instrument the application in order to find out. The error
return trace, on the other hand, shows exactly how the error bubbled up.
This debugging feature makes it easier to iterate quickly on code that robustly handles all error
conditions. This means that Zig developers will naturally find themselves writing correct, robust code in
order to increase their development pace.
Error Return Traces are enabled by default in Debug and ReleaseSafe builds and disabled by default in
ReleaseFast and ReleaseSmall builds.
There are a few ways to activate this error return tracing feature:
Implementation Details
For the case when no errors are returned, the cost is a single memory write operation, only in the first
non-failable function in the call graph that calls a failable function, i.e. when a function returning
void calls a function returning error . This is to initialize this struct in the stack memory:
stack_trace_struct.zig
pub const StackTrace = struct {
index: usize,
instruction_addresses: [N]usize,
};
Here, N is the maximum function call depth as determined by call graph analysis. Recursion is ignored
and counts for 2.
A pointer to StackTrace is passed as a secret parameter to every function that can return an error,
but it's always the first parameter, so it can likely sit in a register and stay there.
That's it for the path when no errors occur. It's practically free in terms of performance.
When generating the code for a function that returns an error, just before the return statement
(only for the return statements that return errors), Zig generates a call to this function:
zig_return_error_fn.zig
�� marked as "no-inline" in LLVM IR
fn ��zig_return_error(stack_trace: *StackTrace) void {
stack_trace.instruction_addresses[stack_trace.index] = @returnAddress
stack_trace.index = (stack_trace.index + 1) % N;
}
The cost is 2 math operations plus some memory reads and writes. The memory accessed is
constrained and should remain cached for the duration of the error return bubbling.
As for code size cost, 1 function call before a return statement is no big deal. Even so, I have a plan to
make the call to ��zig_return_error a tail call, which brings the code size cost down to
actually zero. What is a return statement in code without error return tracing can become a jump
instruction in code with error return tracing.
Optionals
One area that Zig provides safety without compromising efficiency or readability is with the optional
type.
The question mark symbolizes the optional type. You can convert a type to an optional type by putting
a question mark in front of it, like this:
optional_integer.zig
�� normal integer
const normal_int: i32 = 1234;
�� optional integer
const optional_int: ?i32 = 5678;
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.
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.
call_malloc_in_c.c
�� malloc prototype included for reference
void *malloc(size_t size);
Zig code
call_malloc_from_zig.zig
�� malloc prototype included for reference
extern fn malloc(size: usize) ?[*]u8;
fn doAThing() ?*Foo {
const ptr = malloc(1234) orelse return null;
_ = ptr; �� ���
}
Here, Zig is at least as convenient, if not more, than C. And, the type of "ptr" is [*]u8 not ?[*]u8 .
The orelse keyword unwrapped the optional type and therefore ptr is guaranteed to be non-null
everywhere it is used in the function.
The other form of checking against NULL you might see looks like this:
checking_null_in_c.c
void do_a_thing(struct Foo *foo) {
�� do some stuff
if (foo) {
do_something_with_foo(foo);
}
�� do some stuff
}
checking_null_in_zig.zig
const Foo = struct {};
fn doSomethingWithFoo(foo: *Foo) void {
_ = foo;
}
if (optional_foo) |foo| {
doSomethingWithFoo(foo);
}
�� do some stuff
}
Once again, the notable thing here is that inside the if block, foo is no longer an optional pointer, it is
a pointer, which cannot be null.
One benefit to this is that functions which take pointers as arguments can be annotated with the
"nonnull" attribute - ��attribute��((nonnull)) in GCC. The optimizer can sometimes make
better decisions knowing that pointer arguments cannot be null.
Optional Type
An optional is created by putting ? in front of a type. You can use compile-time reflection to access
the child type of an optional:
test_optional_type.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_optional_type.zig
1/1 test_optional_type.test.optional type���OK
All 1 tests passed.
null
Just like undefined, null has its own type, and the only way to use it is to cast it to a different type:
null.zig
const optional_value: ?i32 = null;
Optional Pointers
An optional pointer is guaranteed to be the same size as a pointer. The null of the optional is
guaranteed to be address 0.
test_optional_pointer.zig
const expect = @import("std").testing.expect;
var x: i32 = 1;
ptr = &x;
�� Optional pointers are the same size as normal pointers, because point
�� value 0 is used as the null value.
try expect(@sizeOf(?*i32) �� @sizeOf(*i32));
}
Shell
$ zig test test_optional_pointer.zig
1/1 test_optional_pointer.test.optional pointers���OK
All 1 tests passed.
See also:
Casting
A type cast converts a value of one type to another. Zig has Type Coercion for conversions that are
known to be completely safe and unambiguous, and Explicit Casts for conversions that one would not
want to happen on accident. There is also a third kind of type conversion called Peer Type Resolution
for the case when a result type must be decided given multiple operand types.
Type Coercion
Type coercion occurs when one type is expected, but different type is provided:
test_type_coercion.zig
test "type coercion - variable declaration" {
const a: u8 = 1;
const b: u16 = a;
_ = b;
}
Shell
$ zig test test_type_coercion.zig
1/3 test_type_coercion.test.type coercion - variable declaration���OK
2/3 test_type_coercion.test.type coercion - function call���OK
3/3 test_type_coercion.test.type coercion - @as builtin���OK
All 3 tests passed.
Type coercions are only allowed when it is completely unambiguous how to get from one type to
another, and the transformation is guaranteed to be safe. There is one exception, which is C Pointers.
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:
test_no_op_casts.zig
test "type coercion - const qualification" {
var a: i32 = 1;
const b: *i32 = &a;
foo(b);
}
Shell
$ zig test test_no_op_casts.zig
1/1 test_no_op_casts.test.type coercion - const qualification���OK
All 1 tests passed.
test_pointer_coerce_const_optional.zig
const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;
Shell
$ zig test test_pointer_coerce_const_optional.zig
1/1 test_pointer_coerce_const_optional.test.cast *[1][*:0]const u8 to []cons
All 1 tests passed.
Integers coerce to integer types which can represent every value of the old type, and likewise Floats
coerce to float types which can represent every value of the old type.
test_integer_widening.zig
const std = @import("std");
const builtin = @import("builtin");
const expect = std.testing.expect;
const mem = std.mem;
test "integer widening" {
const a: u8 = 250;
const b: u16 = a;
const c: u32 = b;
const d: u64 = c;
const e: u64 = d;
const f: u128 = e;
try expect(f �� a);
}
Shell
$ zig test test_integer_widening.zig
1/3 test_integer_widening.test.integer widening���OK
2/3 test_integer_widening.test.implicit unsigned integer to signed integer��
3/3 test_integer_widening.test.float widening���OK
All 3 tests passed.
A compiler error is appropriate because this ambiguous expression leaves the compiler two choices
about the coercion.
test_ambiguous_coercion.zig
�� Compile time coercion of float to int
test "implicit cast to comptime_int" {
const f: f32 = 54.0 / 5;
_ = f;
}
Shell
$ zig test test_ambiguous_coercion.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_ambiguous_c
const f: f32 = 54.0 / 5;
~~~~~^��
test_coerce_slices_arrays_and_pointers.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_coerce_slices_arrays_and_pointers.zig
1/7 test_coerce_slices_arrays_and_pointers.test.*const [N]T to []const T���O
2/7 test_coerce_slices_arrays_and_pointers.test.*const [N]T to E![]const T��
3/7 test_coerce_slices_arrays_and_pointers.test.*const [N]T to ?[]const T���
4/7 test_coerce_slices_arrays_and_pointers.test.*[N]T to []T���OK
5/7 test_coerce_slices_arrays_and_pointers.test.*[N]T to [*]T���OK
6/7 test_coerce_slices_arrays_and_pointers.test.*[N]T to ?[*]T���OK
7/7 test_coerce_slices_arrays_and_pointers.test.*T to *[1]T���OK
All 7 tests passed.
See also:
• C Pointers
The payload type of Optionals, as well as null, coerce to the optional type.
test_coerce_optionals.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_coerce_optionals.zig
1/1 test_coerce_optionals.test.coerce to optionals���OK
All 1 tests passed.
test_coerce_optional_wrapped_error_union.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_coerce_optional_wrapped_error_union.zig
1/1 test_coerce_optional_wrapped_error_union.test.coerce to optionals wrappe
All 1 tests passed.
test_coerce_to_error_union.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_coerce_to_error_union.zig
1/1 test_coerce_to_error_union.test.coercion to error unions���OK
All 1 tests passed.
test_coerce_large_to_small.zig
const std = @import("std");
const expect = std.testing.expect;
test "coercing large integer type to smaller one when value is comptime-know
const x: u64 = 255;
const y: u8 = x;
try expect(y �� 255);
}
Shell
$ zig test test_coerce_large_to_small.zig
1/1 test_coerce_large_to_small.test.coercing large integer type to smaller o
All 1 tests passed.
Tagged unions can be coerced to enums, and enums can be coerced to tagged unions when they are
comptime-known to be a field of the union that has only one possible value, such as void:
test_coerce_unions_enums.zig
const std = @import("std");
const expect = std.testing.expect;
const E = enum {
one,
two,
three,
};
const U = union(E) {
one: i32,
two: f32,
three,
};
const U2 = union(enum) {
a: void,
b: f32,
const u_4: U2 = .a; �� coerce enum literal to union with inferred enum t
try expect(u_4.tag() �� 1);
See also:
• union
• enum
Tuples can be coerced to arrays, if all of the fields have the same type.
test_coerce_tuples_arrays.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_coerce_tuples_arrays.zig
1/1 test_coerce_tuples_arrays.test.coercion from homogeneous tuple to array�
All 1 tests passed.
Explicit Casts
Explicit casts are performed via Builtin Functions. Some explicit casts are safe; some are not. Some
explicit casts perform language-level assertions; some do not. Some explicit casts are no-ops at
runtime; some are not.
• switch expressions
• if expressions
• while expressions
• for expressions
• Multiple break statements in a block
• Some binary operations
This kind of type resolution chooses a type that all peer types can coerce into. Here are some
examples:
test_peer_type_resolution.zig
const std = @import("std");
const expect = std.testing.expect;
const mem = std.mem;
return slice[0��1];
}
test "peer type resolution: *[0]u8, []const u8, and anyerror![]u8" {
{
var data = "hi".*;
const slice = data[0��];
try expect((try peerTypeEmptyArrayAndSliceAndError(true, slice)).len
try expect((try peerTypeEmptyArrayAndSliceAndError(false, slice)).le
}
comptime {
var data = "hi".*;
const slice = data[0��];
try expect((try peerTypeEmptyArrayAndSliceAndError(true, slice)).len
try expect((try peerTypeEmptyArrayAndSliceAndError(false, slice)).le
}
}
fn peerTypeEmptyArrayAndSliceAndError(a: bool, slice: []u8) anyerror![]
if (a) {
return &[_]u8{};
}
return slice[0��1];
}
�� The non-error and error cases are only peers if the error case is jus
�� the pattern `x catch |err| blk: { switch (err) {���} }` does not cons
�� and error case to be peers.
const c = a catch |err| switch (err) {
error.A �� 0,
error.B �� 1,
error.C �� null,
};
try expect(@TypeOf(c) �� ?u32);
}
Shell
$ zig test test_peer_type_resolution.zig
1/8 test_peer_type_resolution.test.peer resolve int widening���OK
2/8 test_peer_type_resolution.test.peer resolve arrays of different size to
3/8 test_peer_type_resolution.test.peer resolve array and const slice���OK
4/8 test_peer_type_resolution.test.peer type resolution: ?T and T���OK
5/8 test_peer_type_resolution.test.peer type resolution: *[0]u8 and []const
6/8 test_peer_type_resolution.test.peer type resolution: *[0]u8, []const u8,
7/8 test_peer_type_resolution.test.peer type resolution: *const T and ?*T���
8/8 test_peer_type_resolution.test.peer type resolution: error union switch�
All 8 tests passed.
• void
• The Integers u0 and i0 .
• Arrays and Vectors with len 0, or with an element type that is a zero bit type.
• An enum with only 1 tag.
• A struct with all fields being zero bit types.
• A 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:
zero_bit_types.zig
export fn entry() void {
var x: void = {};
var y: void = {};
x = y;
y = x;
}
When this turns into machine code, there is no code generated in the body of entry , even in 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 epilogue.
void
void can be useful for instantiating generic types. For example, given a Map(Key, Value) , one
can pass void for the Value type to make it into a Set :
test_void_in_hashmap.zig
const std = @import("std");
const expect = std.testing.expect;
try expect(map.contains(2));
try expect(!map.contains(3));
_ = map.remove(2);
try expect(!map.contains(2));
}
Shell
$ zig test test_void_in_hashmap.zig
1/1 test_void_in_hashmap.test.turn HashMap into a set with void���OK
All 1 tests passed.
Note that this is different from using a dummy value for the hash map value. By using void 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.
void is distinct from anyopaque . void has a known size of 0 bytes, and anyopaque has an
unknown, but non-zero, size.
Expressions of type void are the only ones whose value can be ignored. For example, ignoring a
non- void expression is a compile error:
test_expression_ignored.zig
test "ignoring expression value" {
foo();
}
fn foo() i32 {
return 1234;
}
Shell
$ zig test test_expression_ignored.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_expression_
foo();
~~~^~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_expression_
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_expression_
However, if the expression has type void , there will be no error. Expression results can be explicitly
ignored by assigning them to _ .
test_void_ignored.zig
test "void is ignored" {
returnsVoid();
}
fn returnsVoid() void {}
fn foo() i32 {
return 1234;
}
Shell
$ zig test test_void_ignored.zig
1/2 test_void_ignored.test.void is ignored���OK
2/2 test_void_ignored.test.explicitly ignoring expression value���OK
All 2 tests passed.
As a motivating example, consider the statement const x: u32 = 42; . The type annotation
here provides a result type of u32 to the initialization expression 42 , instructing the compiler to
coerce this integer (initially of type comptime_int ) to this type. We will see more examples
shortly.
This is not an implementation detail: the logic outlined above is codified into the Zig language
specification, and is the primary mechanism of type inference in the language. This system is
collectively referred to as "Result Location Semantics".
Result Types
Result types are propagated recursively through expressions where possible. For instance, if the
expression &e has result type *u32 , then e is given a result type of u32 , allowing the language
to perform this coercion before taking a reference.
The result type mechanism is utilized by casting builtins such as @intCast . Rather than taking as
an argument the type to cast to, these builtins use their result type to determine this information. The
result type is often known from context; where it is not, the @as builtin can be used to explicitly
provide a result type.
We can break down the result types for each component of a simple expression as follows:
result_type_propagation.zig
const expectEqual = @import("std").testing.expectEqual;
test "result type propagates through struct initializer" {
const S = struct { x: u32 };
const val: u64 = 123;
const s: S = .{ .x = @intCast(val) };
�� .{ .x = @intCast(val) } has result type `S� due to the type annotat
�� @intCast(val) has result type `u32` due to the type of th
�� val has no result type, as it is permitted to b
try expectEqual(@as(u32, 123), s.x);
}
Shell
$ zig test result_type_propagation.zig
1/1 result_type_propagation.test.result type propagates through struct initi
All 1 tests passed.
This result type information is useful for the aforementioned cast builtins, as well as to avoid the
construction of pre-coercion values, and to avoid the need for explicit type coercions in some cases.
The following table details how some common expressions propagate result types, where x and y
are arbitrary sub-expressions.
Parent Result
Expression Sub-expression Result Type
Type
const val: T =
- x is a T
x
var val: T = x - x is a T
val = x - x is a @TypeOf(val)
@as(T, x) - x is a T
&x *T x is a T
.{ .a = x } T x is a @FieldType(T, "a")
T{ .a = x } - x is a @FieldType(T, "a")
@Type(x) - x is a std.builtin.Type
@typeInfo(x) - x is a type
y is a
x �� y -
std.math.Log2IntCeil(@TypeOf(x))
Result Locations
In addition to result type information, every expression may be optionally assigned a result location: a
pointer to which the value must be directly written. This system can be used to prevent intermediate
copies when initializing data structures, which can be important for types which must have a fixed
memory address ("pinned" types).
When compiling the simple assignment expression x = e , many languages would create the
temporary value e on the stack, and then assign it to x , potentially performing a type coercion in
the process. Zig approaches this differently. The expression e is given a result type matching the type
of x , and a result location of &x . For many syntactic forms of e , this has no practical impact.
However, it can have important semantic effects when working with more complex syntax forms.
This can sometimes be important when assigning an aggregate value where the initialization
expression depends on the previous value of the aggregate. The easiest way to demonstrate this is by
attempting to swap fields of a struct or array - the following logic looks sound, but in fact is not:
result_location_interfering_with_swap.zig
const expect = @import("std").testing.expect;
test "attempt to swap array elements with array initializer" {
var arr: [2]u32 = .{ 1, 2 };
arr = .{ arr[1], arr[0] };
�� The previous line is equivalent to the following two lines:
�� arr[0] = arr[1];
�� arr[1] = arr[0];
�� So this fails!
try expect(arr[0] �� 2); �� succeeds
try expect(arr[1] �� 1); �� fails
}
Shell
$ zig test result_location_interfering_with_swap.zig
1/1 result_location_interfering_with_swap.test.attempt to swap array element
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/testing.zig
if (!ok) return error.TestUnexpectedResult;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/result_location_
try expect(arr[1] �� 1); �� fails
^
0 passed; 0 skipped; 1 failed.
error: the following test command failed with exit code 1:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/8a117bd743
The following table details how some common expressions propagate result locations, where x and
y are arbitrary sub-expressions. Note that some expressions cannot provide meaningful result
locations to sub-expressions, even if they themselves have a result location.
Result
Expression Sub-expression Result Locations
Location
const val: T =
- x has result location &val
x
comptime
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
Compile-time parameters is how Zig implements generics. It is compile-time duck typing.
compile-time_duck_typing.zig
fn max(comptime T: type, a: T, b: T) T {
return if (a > b) a else b;
}
fn gimmeTheBiggerFloat(a: f32, b: f32) f32 {
return max(f32, a, b);
}
fn gimmeTheBiggerInteger(a: u64, b: u64) u64 {
return max(u64, a, b);
}
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 T in the above snippet must be marked with
comptime .
test_unresolved_comptime_value.zig
fn max(comptime T: type, a: T, b: T) T {
return if (a > b) a else b;
}
test "try to pass a runtime type" {
foo(false);
}
fn foo(condition: bool) void {
const result = max(if (condition) f32 else u64, 1234, 5678);
_ = result;
}
Shell
$ zig test test_unresolved_comptime_value.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unresolved_
const result = max(if (condition) f32 else u64, 1234, 5678);
^~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unresolved_
const result = max(if (condition) f32 else u64, 1234, 5678);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_unresolved_
fn max(comptime T: type, a: T, b: T) T {
^~~~~~~~
referenced by:
test.try to pass a runtime type: /home/ci/actions-runner/_work/zig-boots
This is an error because the programmer attempted to pass a value only known at run-time to a
function which expects a value known at compile-time.
Another way to get an error is if we pass a type that violates the type checker when the function is
analyzed. This is what it means to have compile-time duck typing.
For example:
test_comptime_mismatched_type.zig
fn max(comptime T: type, a: T, b: T) T {
return if (a > b) a else b;
}
test "try to compare bools" {
_ = max(bool, true, false);
}
Shell
$ zig test test_comptime_mismatched_type.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_mi
return if (a > b) a else b;
��^��
referenced by:
test.try to compare bools: /home/ci/actions-runner/_work/zig-bootstrap/z
On the flip side, inside the function definition with the comptime parameter, the value is known at
compile-time. This means that we actually could make this work for the bool type if we wanted to:
test_comptime_max_with_bool.zig
fn max(comptime T: type, a: T, b: T) T {
if (T �� bool) {
return a or b;
} else if (a > b) {
return a;
} else {
return b;
}
}
test "try to compare bools" {
try @import("std").testing.expect(max(bool, false, true) �� true);
}
Shell
$ zig test test_comptime_max_with_bool.zig
1/1 test_comptime_max_with_bool.test.try to compare bools���OK
All 1 tests passed.
This works because Zig implicitly inlines if expressions when the condition is known at compile-
time, and the compiler guarantees that it will skip analysis of the branch not taken.
This means that the actual function generated for max in this situation looks like this:
compiler_generated_function.zig
fn max(a: bool, b: bool) bool {
{
return a or b;
}
}
All the code that dealt with compile-time known values is eliminated and we are left with only the
necessary run-time code to accomplish the task.
This works the same way for switch expressions - they are implicitly inlined when the target
expression is compile-time known.
Compile-Time Variables
In Zig, the programmer can label variables as comptime . This guarantees to the compiler that every
load and store of the variable is performed at compile-time. Any violation of this results in a compile
error.
This combined with the fact that we can inline loops allows us to write a function which is partially
evaluated at compile-time and partially at run-time.
For example:
test_comptime_evaluation.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_comptime_evaluation.zig
1/1 test_comptime_evaluation.test.perform fn���OK
All 1 tests passed.
This example is a bit contrived, because the compile-time evaluation component is unnecessary; this
code would work fine if it was all done at run-time. But it does end up generating different code. In this
example, the function performFn is generated three different times, for the different values of
prefix_char provided:
performFn_1
�� From the line:
�� expect(performFn('t', 1) �� 6);
fn performFn(start_value: i32) i32 {
var result: i32 = start_value;
result = two(result);
result = three(result);
return result;
}
performFn_2
�� From the line:
�� expect(performFn('o', 0) �� 1);
fn performFn(start_value: i32) i32 {
var result: i32 = start_value;
result = one(result);
return result;
}
performFn_3
�� From the line:
�� expect(performFn('w', 99) �� 99);
fn performFn(start_value: i32) i32 {
var result: i32 = start_value;
_ = &result;
return result;
}
Note that this happens even in a debug build. This is not a way to write more optimized code, but it is a
way to make sure that what should happen at compile-time, does happen at compile-time. This
catches more errors and allows expressiveness that in other languages requires using macros,
generated code, or a preprocessor to accomplish.
Compile-Time Expressions
In Zig, it matters whether a given expression is known at compile-time or run-time. A programmer can
use a comptime expression to guarantee that the expression will be evaluated at compile-time. If
this cannot be accomplished, the compiler will emit an error. For example:
test_comptime_call_extern_function.zig
extern fn exit() noreturn;
test "foo" {
comptime {
exit();
}
}
Shell
$ zig test test_comptime_call_extern_function.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_ca
exit();
~~~~^~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_ca
comptime {
^~~~~~~~
It doesn't make sense that a program could call exit() (or any other external function) at compile-
time, so this is a compile error. However, a comptime expression does much more than sometimes
cause a compile error.
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.
test_fibonacci_recursion.zig
const expect = @import("std").testing.expect;
test "fibonacci" {
�� test fibonacci at run-time
try expect(fibonacci(7) �� 13);
Imagine if we had forgotten the base case of the recursive function and tried to run the tests:
test_fibonacci_comptime_overflow.zig
const expect = @import("std").testing.expect;
test "fibonacci" {
try comptime expect(fibonacci(7) �� 13);
}
Shell
$ zig test test_fibonacci_comptime_overflow.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_fibonacci_c
return fibonacci(index - 1) + fibonacci(index - 2);
~~~~~~^��
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_fibonacci_c
return fibonacci(index - 1) + fibonacci(index - 2);
~~~~~~~~~^~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_fibonacci_c
try comptime expect(fibonacci(7) �� 13);
~~~~~~~~~^��
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 Illegal
Behavior, which is always a compile error if the compiler knows it happened. But what would have
happened if we used a signed integer?
fibonacci_comptime_infinite_recursion.zig
const assert = @import("std").debug.assert;
test "fibonacci" {
try comptime assert(fibonacci(7) �� 13);
}
The compiler is supposed to notice that evaluating this function at compile-time took more than 1000
branches, and thus emits an error and gives up. If the programmer wants to increase the budget for
compile-time computation, they can use a built-in function called @setEvalBranchQuota to change the
default number 1000 to something else.
However, there is a design flaw in the compiler causing it to stack overflow instead of having the proper
behavior here. I'm terribly sorry about that. I hope to get this resolved before the next release.
What if we fix the base case, but put the wrong value in the expect line?
test_fibonacci_comptime_unreachable.zig
const assert = @import("std").debug.assert;
test "fibonacci" {
try comptime assert(fibonacci(7) �� 99999);
}
Shell
$ zig test test_fibonacci_comptime_unreachable.zig
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/debug.zig:5
if (!ok) unreachable; �� assertion failure
^~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_fibonacci_c
try comptime assert(fibonacci(7) �� 99999);
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
At container level (outside of any function), all expressions are implicitly comptime expressions.
This means that we can use functions to initialize complex static data. For example:
test_container-level_comptime_expressions.zig
const first_25_primes = firstNPrimes(25);
const sum_of_first_25_primes = sum(&first_25_primes);
fn firstNPrimes(comptime n: usize) [n]i32 {
var prime_list: [n]i32 = undefined;
var next_index: usize = 0;
var test_number: i32 = 2;
while (next_index < prime_list.len) : (test_number += 1) {
var test_prime_index: usize = 0;
var is_prime = true;
while (test_prime_index < next_index) : (test_prime_index +=
if (test_number % prime_list[test_prime_index] �� 0) {
is_prime = false;
break;
}
}
if (is_prime) {
prime_list[next_index] = test_number;
next_index += 1;
}
}
return prime_list;
}
Shell
$ zig test test_container-level_comptime_expressions.zig
1/1 test_container-level_comptime_expressions.test.variable values���OK
All 1 tests passed.
When we compile this program, Zig generates the constants with the answer pre-computed. Here are
the lines from the generated LLVM IR:
Note that we did not have to do anything special with the syntax of these functions. For example, we
could call the sum function as is with a slice of numbers whose length and values were only known at
run-time.
Zig uses comptime capabilities to implement generic data structures without introducing any special-
case syntax.
generic_data_structure.zig
fn List(comptime T: type) type {
return struct {
items: []T,
len: usize,
};
}
That's it. It's a function that returns an anonymous struct . For the purposes of error messages and
debugging, Zig infers the name "List(i32)" from the function name and parameters invoked
when creating the anonymous struct.
anonymous_struct_name.zig
const Node = struct {
next: ?*Node,
name: []const u8,
};
Putting all of this together, let's see how print works in Zig.
print.zig
const print = @import("std").debug.print;
Shell
$ zig build-exe print.zig
$ ./print
here is a string: 'foobar' here is a number: 1234
Let's crack open the implementation of this and see how it works:
poc_print_fn.zig
const Writer = struct {
��� Calls print and then flushes the buffer.
pub fn print(self: *Writer, comptime format: []const u8, args: anytype
const State = enum {
start,
open_brace,
close_brace,
};
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:
printValue is a function that takes a parameter of any type, and does different things depending
on the type:
poc_printValue_fn.zig
const Writer = struct {
pub fn printValue(self: *Writer, value: anytype) !void {
switch (@typeInfo(@TypeOf(value))) {
.int �� {
return self.writeInt(value);
},
.float �� {
return self.writeFloat(value);
},
.pointer �� {
return self.write(value);
},
else �� {
@compileError("Unable to print type '" �� @typeName(@TypeOf
},
}
}
test_print_too_many_args.zig
const print = @import("std").debug.print;
Shell
$ zig test test_print_too_many_args.zig
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/Io/Writer.z
Zig doesn't care whether the format argument is a string literal, only that it is a compile-time known
value that can be coerced to a []const u8 :
print_comptime-known_format.zig
const print = @import("std").debug.print;
Shell
$ zig build-exe print_comptime-known_format.zig
$ ./print_comptime-known_format
here is a string: 'foobar' here is a number: 1234
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.
See also:
• inline while
• inline for
Assembly
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:
inline_assembly.zig
pub fn main() noreturn {
const msg = "hello world\n";
_ = syscall3(SYS_write, STDOUT_FILENO, @intFromPtr(msg), msg.len);
_ = syscall1(SYS_exit, 0);
unreachable;
}
pub const SYS_write = 1;
pub const SYS_exit = 60;
Shell
$ zig build-exe inline_assembly.zig -target x86_64-linux
$ ./inline_assembly
hello world
For x86 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
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
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
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 "memory" 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 Illegal
Behavior.
Global Assembly
When an assembly expression occurs in a container level comptime block, this is global assembly.
This kind of assembly has different rules than inline assembly. First, volatile 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.
test_global_assembly.zig
const std = @import("std");
const expect = std.testing.expect;
comptime {
asm (
\\.global my_func;
\\.type my_func, @function;
\\my_func:
\\ lea (%rdi,%rsi,1),%eax
\\ retq
);
}
Shell
$ zig test test_global_assembly.zig -target x86_64-linux -fllvm
1/1 test_global_assembly.test.global assembly���OK
All 1 tests passed.
Atomics
TODO: @atomic rmw
See also:
• @atomicLoad
• @atomicStore
• @atomicRmw
• @cmpxchgWeak
• @cmpxchgStrong
Async Functions
Async functions regressed with the release of 0.11.0. The current plan is to reintroduce them as a
lower level primitive that powers I/O implementations.
Builtin Functions
Builtin functions are provided by the compiler and are prefixed with @ . The comptime keyword on
a parameter means that the parameter must be known at compile time.
@addrSpaceCast
Converts a pointer from one address space to another. The new address space is inferred based on the
result type. Depending on the current target and address spaces, this cast may be a no-op, a complex
operation, or illegal. If the cast is legal, then the resulting pointer points to the same memory location
as the pointer operand. It is always valid to cast a pointer between the same address spaces.
@addWithOverflow
Performs a + b and returns a tuple with the result and a possible overflow bit.
@alignCast
ptr can be *T , ?*T , or []T . Changes the alignment of a pointer. The alignment to use is
inferred based on the result type.
A pointer alignment safety check is added to the generated code to make sure the pointer is aligned as
promised.
@alignOf
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.
The result is a target-specific compile time constant. It is guaranteed to be less than or equal to
@sizeOf(T).
See also:
• Alignment
@as
Performs Type Coercion. This cast is allowed when the conversion is unambiguous and safe, and is the
preferred way to convert between types, whenever possible.
@atomicLoad
This builtin function atomically dereferences a pointer to a T and returns the value.
See also:
• @atomicStore
• @atomicRmw
• @cmpxchgWeak
• @cmpxchgStrong
@atomicRmw
This builtin function dereferences a pointer to a T and atomically modifies the value and returns the
previous value.
See also:
• @atomicStore
• @atomicLoad
• @cmpxchgWeak
• @cmpxchgStrong
@atomicStore
This builtin function dereferences a pointer to a T and atomically stores the given value.
See also:
• @atomicLoad
• @atomicRmw
• @cmpxchgWeak
• @cmpxchgStrong
@bitCast
Converts a value of one type to another type. The return type is the inferred result type.
Works at compile-time if value 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.
@bitOffsetOf
For non packed structs, this will always be divisible by 8 . For packed structs, non-byte-aligned fields
will share a byte offset, but they will have different bit offsets.
See also:
• @offsetOf
@bitSizeOf
This function returns the number of bits it takes to store T 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
comptime_int and type , the result is 0 .
See also:
• @sizeOf
• @typeInfo
@branchHint
Hints to the optimizer how likely a given branch of control flow is to be reached.
This function is only valid as the first statement in a control flow branch, or the first statement in a
function.
@breakpoint
@breakpoint() void
This function inserts a platform-specific debug trap instruction which causes debuggers to break there.
Unlike for @trap() , execution may continue after this point if the program is resumed.
See also:
• @trap
@mulAdd
@mulAdd(comptime T: type, a: T, b: T, c: T) T
Fused multiply-add, similar to (a * b) + c , except only rounds once, and is thus more accurate.
@byteSwap
@byteSwap(operand: anytype) T
@TypeOf(operand) must be an integer type or an integer vector type with bit count evenly
divisible by 8.
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 @sizeOf bytes. This is demonstrated with u24 .
@sizeOf(u24) �� 4 , which means that a u24 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 T is specified to be
u24 , then only 3 bytes are reversed.
@bitReverse
@bitReverse(integer: anytype) T
Reverses the bitpattern of an integer value, including the sign bit if applicable.
@offsetOf
See also:
• @bitOffsetOf
@call
Calls a function, in the same way that invoking an expression with parentheses does:
test_call_builtin.zig
const expect = @import("std").testing.expect;
Shell
$ zig test test_call_builtin.zig
1/1 test_call_builtin.test.noinline function call���OK
All 1 tests passed.
@call allows more flexibility than normal function call syntax does. The CallModifier enum is
reproduced here:
builtin.CallModifier struct.zig
pub const CallModifier = enum {
��� Equivalent to function call syntax.
auto,
��� Prevents tail call optimization. This guarantees that the return
��� address will point to the callsite, as opposed to the callsite's
��� callsite. If the call is otherwise required to be tail-called
��� or inlined, a compile error is emitted instead.
never_tail,
��� Guarantees that the call will not be inlined. If the call is
��� otherwise required to be inlined, a compile error is emitted instead
never_inline,
��� Asserts that the function call will not suspend. This allows a
��� non-async function to call an async function.
no_async,
��� Guarantees that the call will be generated with tail call optimizati
��� If this is not possible, a compile error is emitted instead.
always_tail,
@cDefine
#define _GNU_SOURCE
@cDefine("_GNU_SOURCE", {})
See also:
@cImport
@cImport(expression) type
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.
Usually you should only have one @cImport in your entire application, because it saves the
compiler from invoking clang multiple times, and prevents inline functions from being duplicated.
• 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
See also:
@cInclude
See also:
@clz
Counts the number of most-significant (leading in a big-endian sense) zeroes in an integer - "count
leading zeroes".
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.
See also:
• @ctz
• @popCount
@cmpxchgStrong
This function performs a strong atomic compare-and-exchange operation, returning null if the
current value is the given expected value. It's the equivalent of this code, except atomic:
not_atomic_cmpxchgStrong.zig
fn cmpxchgStrongButNotAtomic(comptime T: type, ptr: *T, expected_value: T, n
const old_value = ptr.*;
if (old_value �� expected_value) {
ptr.* = new_value;
return null;
} else {
return old_value;
}
}
If you are using cmpxchg in a retry loop, @cmpxchgWeak is the better choice, because it can be
implemented more efficiently in machine instructions.
See also:
• @atomicStore
• @atomicLoad
• @atomicRmw
• @cmpxchgWeak
@cmpxchgWeak
This function performs a weak atomic compare-and-exchange operation, returning null if the
current value is the given expected value. It's the equivalent of this code, except atomic:
cmpxchgWeakButNotAtomic
fn cmpxchgWeakButNotAtomic(comptime T: type, ptr: *T, expected_value: T, new
const old_value = ptr.*;
if (old_value �� expected_value and usuallyTrueButSometimesFalse()) {
ptr.* = new_value;
return null;
} else {
return old_value;
}
}
If you are using cmpxchg in a retry loop, the sporadic failure will be no problem, and cmpxchgWeak
is the better choice, because it can be implemented more efficiently in machine instructions. However
if you need a stronger guarantee, use @cmpxchgStrong.
See also:
• @atomicStore
• @atomicLoad
• @atomicRmw
• @cmpxchgStrong
@compileError
This function, when semantically analyzed, causes a compile error with the message msg .
There are several ways that code avoids being semantically checked, such as using if or switch
with compile time constants, and comptime functions.
@compileLog
@compileLog(���) void
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.
test_compileLog_builtin.zig
const print = @import("std").debug.print;
test "main" {
@compileLog("comptime in main");
Shell
$ zig test test_compileLog_builtin.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_compileLog_
@compileLog("comptime val1 = ", val1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_compileLog_
@compileLog("comptime in main");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
test.main: /home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/t
@constCast
@ctz
Counts the number of least-significant (trailing in a big-endian sense) zeroes in an integer - "count
trailing zeroes".
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.
See also:
• @clz
• @popCount
@cUndef
See also:
@cVaArg
See also:
• @cVaCopy
• @cVaEnd
• @cVaStart
@cVaCopy
See also:
• @cVaArg
• @cVaEnd
• @cVaStart
@cVaEnd
See also:
• @cVaArg
• @cVaCopy
• @cVaStart
@cVaStart
@cVaStart() std.builtin.VaList
See also:
• @cVaArg
• @cVaCopy
• @cVaEnd
@divExact
@divExact(numerator: T, denominator: T) T
Exact division. Caller guarantees denominator �� 0 and @divTrunc(numerator,
denominator) * denominator �� numerator .
• @divExact(6, 3) �� 2
• @divExact(a, b) * b �� a
See also:
• @divTrunc
• @divFloor
@divFloor
@divFloor(numerator: T, denominator: T) T
Floored division. Rounds toward negative infinity. For unsigned integers it is the same as
numerator / denominator . Caller guarantees denominator �� 0 and !
(@typeInfo(T) �� .int and T.is_signed and numerator ��
std.math.minInt(T) and denominator �� -1) .
• @divFloor(-5, 3) �� -2
• (@divFloor(a, b) * b) + @mod(a, b) �� a
See also:
• @divTrunc
• @divExact
@divTrunc
@divTrunc(numerator: T, denominator: T) T
Truncated division. Rounds toward zero. For unsigned integers it is the same as numerator /
denominator . Caller guarantees denominator �� 0 and !(@typeInfo(T) �� .int
and T.is_signed and numerator �� std.math.minInt(T) and denominator
�� -1) .
• @divTrunc(-5, 3) �� -1
• (@divTrunc(a, b) * b) + @rem(a, b) �� a
• @divFloor
• @divExact
@embedFile
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 path . The contents of the array are the contents of the
file. This is equivalent to a string literal with the file contents.
See also:
• @import
@enumFromInt
Converts an integer into an enum value. The return type is the inferred result type.
Attempting to convert an integer with no corresponding value in the enum invokes safety-checked
Illegal Behavior. Note that a non-exhaustive enum has corresponding values for all integers in the
enum's integer tag type: the _ value represents all the remaining unnamed integers in the enum's tag
type.
See also:
• @intFromEnum
@errorFromInt
Converts from the integer representation of an error into 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-checked Illegal
Behavior.
See also:
• @intFromError
@errorName
This function returns the string representation of an error. The string representation of
error.OutOfMem is "OutOfMem" .
If there are no calls to @errorName in an entire application, or all calls have a compile-time known
value for err , then no error name table will be generated.
@errorReturnTrace
@errorReturnTrace() ?*builtin.StackTrace
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 null.
@errorCast
Converts an error set or error union value from one error set to another error set. The return type is the
inferred result type. Attempting to convert an error which is not in the destination error set results in
safety-checked Illegal Behavior.
@export
Creates a symbol in the output object file which refers to the target of ptr .
This builtin can be called from a comptime block to conditionally export symbols. When ptr points
to a function with the C calling convention and options.linkage is .Strong , this is
equivalent to the export keyword used on a function:
export_builtin.zig
comptime {
@export(&internalName, .{ .name = "foo", .linkage = .strong });
}
Shell
$ zig build-obj export_builtin.zig
export_builtin_equivalent_code.zig
export fn foo() void {}
Shell
$ zig build-obj export_builtin_equivalent_code.zig
Note that even when using export , the @"foo" syntax for identifiers can be used to choose any
string for the symbol name:
export_any_symbol_name.zig
export fn @"A function name that is a complete sentence."() void {}
Shell
$ zig build-obj export_any_symbol_name.zig
When looking at the resulting object, you can see the symbol is used verbatim:
See also:
• Exporting a C Library
@extern
Creates a reference to an external symbol in the output object file. T must be a pointer type.
See also:
• @export
@field
@field(lhs: anytype, comptime field_name: []const u8) (field)
Performs field access by a compile-time string. Works on both fields and declarations.
test_field_builtin.zig
const std = @import("std");
@field(p, "x") = 4;
@field(p, "y") = @field(p, "x") + 1;
@field(Point, "z") = 2;
try expect(@field(Point, "z") �� 2);
}
Shell
$ zig test test_field_builtin.zig
1/2 test_field_builtin.test.field access by string���OK
2/2 test_field_builtin.test.decl access by string���OK
All 2 tests passed.
@fieldParentPtr
Given a pointer to a struct field, returns a pointer to the struct containing that field. The return type
(and struct in question) is the inferred result type.
If field_ptr does not point to the field_name field of an instance of the result type, and the
result type has ill-defined layout, invokes unchecked Illegal Behavior.
@FieldType
Given a type and the name of one of its fields, returns the type of that field.
@floatCast
Convert from one float type to another. This cast is safe, but may cause the numeric value to lose
precision. The return type is the inferred result type.
@floatFromInt
Converts an integer to the closest floating point representation. The return type is the inferred result
type. To convert the other way, use @intFromFloat. This operation is legal for all values of all integer
types.
@frameAddress
@frameAddress() usize
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.
@hasDecl
test_hasDecl_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
test "@hasDecl" {
try expect(@hasDecl(Foo, "blah"));
�� Even though `hi` is private, @hasDecl returns true because this test
�� in the same file scope as Foo. It would return false if Foo was decla
�� in a different file.
try expect(@hasDecl(Foo, "hi"));
Shell
$ zig test test_hasDecl_builtin.zig
1/1 test_hasDecl_builtin.test.@hasDecl���OK
All 1 tests passed.
See also:
• @hasField
@hasField
See also:
• @hasDecl
@import
This function finds a zig file corresponding to path 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. @import returns the struct type corresponding to the file.
Declarations which have the pub keyword may be referenced from a different source file than the
one they are declared in.
path 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 @import function call.
See also:
• Compile Variables
• @embedFile
@inComptime
@inComptime() bool
Returns whether the builtin was run in a comptime context. The result is a compile-time constant.
This can be used to provide alternative, comptime-friendly implementations of functions. It should not
be used, for instance, to exclude certain functions from being evaluated at comptime.
See also:
• comptime
@intCast
test_intCast_builtin.zig
test "integer cast panic" {
var a: u16 = 0xabcd; �� runtime-known
_ = &a;
const b: u8 = @intCast(a);
_ = b;
}
Shell
$ zig test test_intCast_builtin.zig
1/1 test_intCast_builtin.test.integer cast panic���thread 3655504 panic: int
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_intCast_bui
const b: u8 = @intCast(a);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/871b53b58c
To truncate the significant bits of a number out of range of the destination type, use @truncate.
@intFromBool
@intFromBool(value: bool) u1
@intFromEnum
@intFromEnum(enum_or_tagged_union: anytype) anytype
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 comptime_int known at comptime.
See also:
• @enumFromInt
@intFromError
It is generally recommended to avoid this cast, as the integer representation of an error is not stable
across source code changes.
See also:
• @errorFromInt
@intFromFloat
Converts the integer part of a floating point number to the inferred result type.
If the integer part of the floating point number cannot fit in the destination type, it invokes safety-
checked Illegal Behavior.
See also:
• @floatFromInt
@intFromPtr
@intFromPtr(value: anytype) usize
Converts value to a usize which is the address of the pointer. value can be *T or ?*T .
@max
@max(���) T
Takes two or more arguments and returns the biggest value included (the maximum). This builtin
accepts integers, floats, and vectors of either. In the latter case, the operation is performed element
wise.
NaNs are handled as follows: return the biggest non-NaN value included. If all operands are NaN,
return NaN.
See also:
• @min
• Vectors
@memcpy
dest must be a mutable slice, a mutable pointer to an array, or a mutable many-item pointer. It may
have any alignment, and it may have any element type.
source must be a slice, a pointer to an array, or a many-item pointer. It may have any alignment,
and it may have any element type.
The source element type must have the same in-memory representation as the dest element
type.
Similar to for loops, at least one of source and dest must provide a length, and if two lengths are
provided, they must be equal.
@memset
dest must be a mutable slice or a mutable pointer to an array. It may have any alignment, and it may
have any element type.
For securely zeroing out sensitive contents from memory, you should use
std.crypto.secureZero
@memmove
This function copies bytes from one region of memory to another, but unlike @memcpy the regions
may overlap.
dest must be a mutable slice, a mutable pointer to an array, or a mutable many-item pointer. It may
have any alignment, and it may have any element type.
source must be a slice, a pointer to an array, or a many-item pointer. It may have any alignment,
and it may have any element type.
The source element type must have the same in-memory representation as the dest element
type.
Similar to for loops, at least one of source and dest must provide a length, and if two lengths are
provided, they must be equal.
@min
@min(���) T
Takes two or more arguments and returns the smallest value included (the minimum). This builtin
accepts integers, floats, and vectors of either. In the latter case, the operation is performed element
wise.
NaNs are handled as follows: return the smallest non-NaN value included. If all operands are NaN,
return NaN.
See also:
• @max
• Vectors
@wasmMemorySize
@wasmMemorySize(index: u32) usize
This function returns the size of the Wasm memory identified by index 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
@import("std").heap.WasmPageAllocator .
See also:
• @wasmMemoryGrow
@wasmMemoryGrow
This function increases the size of the Wasm memory identified by index by delta 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
@import("std").heap.WasmPageAllocator .
test_wasmMemoryGrow_builtin.zig
const std = @import("std");
const native_arch = @import("builtin").target.cpu.arch;
const expect = std.testing.expect;
test "@wasmMemoryGrow" {
if (native_arch �� .wasm32) return error.SkipZigTest;
Shell
$ zig test test_wasmMemoryGrow_builtin.zig
1/1 test_wasmMemoryGrow_builtin.test.@wasmMemoryGrow���SKIP
0 passed; 1 skipped; 0 failed.
See also:
• @wasmMemorySize
@mod
@mod(numerator: T, denominator: T) T
Modulus division. For unsigned integers this is the same as numerator % denominator . Caller
guarantees denominator > 0 , otherwise the operation will result in a Remainder Division by Zero
when runtime safety checks are enabled.
• @mod(-5, 3) �� 1
• (@divFloor(a, b) * b) + @mod(a, b) �� a
See also:
• @rem
@mulWithOverflow
Performs a * b and returns a tuple with the result and a possible overflow bit.
@panic
Invokes the panic handler function. By default the panic handler function calls the public panic
function exposed in the root source file, or if there is not one specified, the
std.builtin.default_panic function from std/builtin.zig .
• 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.
See also:
• Panic Handler
@popCount
@popCount(operand: anytype) anytype
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.
See also:
• @ctz
• @clz
@prefetch
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 no-op. This function has no
effect on the behavior of the program, only on the performance characteristics.
The ptr 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.
@ptrCast
Converts a pointer of one type to a pointer of another type. The return type is the inferred result type.
Optional Pointers are allowed. Casting an optional pointer which is null to a non-optional pointer
invokes safety-checked Illegal Behavior.
@ptrFromInt
Converts an integer to a pointer. The return type is the inferred result type. To convert the other way,
use @intFromPtr. Casting an address of 0 to a destination type which in not optional and does not have
the allowzero attribute will result in a Pointer Cast Invalid Null panic when runtime safety checks
are enabled.
If the destination pointer type does not allow address zero and address is zero, this invokes safety-
checked Illegal Behavior.
@rem
@rem(numerator: T, denominator: T) T
Remainder division. For unsigned integers this is the same as numerator % denominator .
Caller guarantees denominator > 0 , otherwise the operation will result in a Remainder Division
by Zero when runtime safety checks are enabled.
• @rem(-5, 3) �� -2
• (@divTrunc(a, b) * b) + @rem(a, b) �� a
See also:
• @mod
@returnAddress
@returnAddress() usize
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.
@select
@select(comptime T: type, pred: @Vector(len, bool), a: @Vector(len, T), b:
See also:
• Vectors
@setEvalBranchQuota
Increase the maximum number of backwards branches that compile-time code execution can use
before giving up and making a compile error.
If the new_quota is smaller than the default quota ( 1000 ) or a previously explicitly set quota, it is
ignored.
Example:
test_without_setEvalBranchQuota_builtin.zig
test "foo" {
comptime {
var i = 0;
while (i < 1001) : (i += 1) {}
}
}
Shell
$ zig test test_without_setEvalBranchQuota_builtin.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_without_set
while (i < 1001) : (i += 1) {}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_without_set
test_setEvalBranchQuota_builtin.zig
test "foo" {
comptime {
@setEvalBranchQuota(1001);
var i = 0;
while (i < 1001) : (i += 1) {}
}
}
Shell
$ zig test test_setEvalBranchQuota_builtin.zig
1/1 test_setEvalBranchQuota_builtin.test.foo���OK
All 1 tests passed.
See also:
• comptime
@setFloatMode
Changes the current scope's rules about how floating point operations are defined.
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.
See also:
@setRuntimeSafety
test_setRuntimeSafety_builtin.zig
test "@setRuntimeSafety" {
�� The builtin applies to the scope that it is called in. So here, integ
�� will not be caught in ReleaseFast and ReleaseSmall modes:
�� var x: u8 = 255;
�� x += 1; �� Unchecked Illegal Behavior in ReleaseFast/ReleaseSmall mod
{
�� However this block has safety enabled, so safety checks happen he
�� even in ReleaseFast and ReleaseSmall modes.
@setRuntimeSafety(true);
var x: u8 = 255;
x += 1;
{
�� The value can be overridden at any scope. So here integer ove
�� would not be caught in any build mode.
@setRuntimeSafety(false);
�� var x: u8 = 255;
�� x += 1; �� Unchecked Illegal Behavior in all build modes.
}
}
}
Shell
$ zig test test_setRuntimeSafety_builtin.zig -OReleaseFast
1/1 test_setRuntimeSafety_builtin.test.@setRuntimeSafety���thread 3656694 pa
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_setRuntimeS
x += 1;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/cfb5e2ed6a
Performs the left shift operation ( �� ). For unsigned integers, the result is undefined if any 1 bits are
shifted out. For signed integers, the result is undefined if any bits that disagree with the resultant sign
bit are shifted out.
comptime_int is modeled as an integer with an infinite number of bits, meaning that in such case,
@shlExact always produces a result and cannot produce a compile error.
See also:
• @shrExact
• @shlWithOverflow
@shlWithOverflow
Performs a �� b and returns a tuple with the result and a possible overflow bit.
See also:
• @shlExact
• @shrExact
@shrExact
Performs the right shift operation ( �� ). Caller guarantees that the shift will not shift any 1 bits out.
• @shlExact
• @shlWithOverflow
@shuffle
Each element in mask selects an element from either a or b . Positive numbers select from a
starting at 0. Negative values select from b , starting at -1 and going down. It is recommended to
use the ~ operator for indexes from b so that both indexes can start from 0 (i.e. ��as(i32,
0) is -1 ).
For each element of mask , if it or the selected value from a or b is undefined , then the
resulting element is undefined .
a_len and b_len may differ in length. Out-of-bounds element indexes in mask result in
compile errors.
E must be an integer, float, pointer, or bool . The mask may be any vector length, and its length
determines the result length.
test_shuffle_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_shuffle_builtin.zig
1/1 test_shuffle_builtin.test.vector @shuffle���OK
All 1 tests passed.
See also:
• Vectors
@sizeOf
This function returns the number of bytes it takes to store T 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, the padding would be
the offset in bytes between element at index 0 and the element at index 1. For integer, consider
whether you want to use @sizeOf(T) or @typeInfo(T).int.bits .
This function measures the size at runtime. For types that are disallowed at runtime, such as
comptime_int and type , the result is 0 .
See also:
• @bitSizeOf
• @typeInfo
@splat
Produces an array or vector where each element is the value scalar . The return type and thus the
length of the vector is inferred.
test_splat_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_splat_builtin.zig
1/2 test_splat_builtin.test.vector @splat���OK
2/2 test_splat_builtin.test.array @splat���OK
All 2 tests passed.
See also:
• Vectors
• @shuffle
@reduce
Transforms a vector into a scalar value (of type E ) by performing a sequential horizontal reduction of
its elements using the specified operator op .
Note that .Add and .Mul reductions on integral types are wrapping; when applied on floating
point types the operation associativity is preserved, unless the float mode is set to Optimized .
test_reduce_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_reduce_builtin.zig
1/1 test_reduce_builtin.test.vector @reduce���OK
All 1 tests passed.
See also:
• Vectors
• @setFloatMode
@src
@src() std.builtin.SourceLocation
Returns a SourceLocation struct representing the function's name and location in the source
code. This must be called in a function.
test_src_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
test "@src" {
try doTheTest();
}
fn doTheTest() !void {
const src = @src();
Shell
$ zig test test_src_builtin.zig
1/1 test_src_builtin.test.@src���OK
All 1 tests passed.
@sqrt
Performs the square root of a floating point number. Uses a dedicated hardware instruction when
available.
@sin
Sine trigonometric function on a floating point number in radians. Uses a dedicated hardware
instruction when available.
@cos
Cosine trigonometric function on a floating point number in radians. Uses a dedicated hardware
instruction when available.
@tan
Tangent trigonometric function on a floating point number in radians. Uses a dedicated hardware
instruction when available.
@exp
Base-e exponential function on a floating point number. Uses a dedicated hardware instruction when
available.
@exp2
Base-2 exponential function on a floating point number. Uses a dedicated hardware instruction when
available.
@log
Returns the natural logarithm of a floating point number. Uses a dedicated hardware instruction when
available.
@log2
Returns the logarithm to the base 2 of a floating point number. Uses a dedicated hardware instruction
when available.
@log10
Returns the logarithm to the base 10 of a floating point number. Uses a dedicated hardware instruction
when available.
@abs
@floor
Returns the largest integral value not greater than the given floating point number. Uses a dedicated
hardware instruction when available.
@ceil
Returns the smallest integral value not less than the given floating point number. Uses a dedicated
hardware instruction when available.
@trunc
Rounds the given floating point number to an integer, towards zero. Uses a dedicated hardware
instruction when available.
@round
Rounds the given floating point number to the nearest integer. If two integers are equally close, rounds
away from zero. Uses a dedicated hardware instruction when available.
test_round_builtin.zig
const expect = @import("std").testing.expect;
test "@round" {
try expect(@round(1.4) �� 1);
try expect(@round(1.5) �� 2);
try expect(@round(-1.4) �� -1);
try expect(@round(-2.5) �� -3);
}
Shell
$ zig test test_round_builtin.zig
1/1 test_round_builtin.test.@round���OK
All 1 tests passed.
@subWithOverflow
Performs a - b and returns a tuple with the result and a possible overflow bit.
@tagName
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
Illegal Behavior.
@This
@This() type
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:
test_this_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
test "@This()" {
var items = [_]i32{ 1, 2, 3, 4 };
const list = List(i32){ .items = items[0��] };
try expect(list.length() �� 4);
}
items: []T,
Shell
$ zig test test_this_builtin.zig
1/1 test_this_builtin.test.@This()���OK
All 1 tests passed.
When @This() is used at file scope, it returns a reference to the struct that corresponds to the
current file.
@trap
@trap() noreturn
This function inserts a platform-specific trap/jam instruction which can be used to exit the program
abnormally. This may be implemented by explicitly emitting an invalid instruction which may cause an
illegal instruction exception of some sort. Unlike for @breakpoint() , execution does not continue
after this point.
See also:
• @breakpoint
@truncate
This function truncates bits from an integer type, resulting in a smaller or same-sized integer type. The
return type is the inferred result type.
This function always truncates the significant bits of the integer, regardless of endianness on the target
platform.
Calling @truncate on a number out of range of the destination type is well defined and working
code:
test_truncate_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_truncate_builtin.zig
1/1 test_truncate_builtin.test.integer truncation���OK
All 1 tests passed.
@Type
This function is the inverse of @typeInfo. It reifies type information into a type .
• type
• noreturn
• void
• bool
• Integers - The maximum bit count for an integer type is 65535 .
• Floats
• Pointers
• comptime_int
• comptime_float
• @TypeOf(undefined)
• @TypeOf(null)
• Arrays
• Optionals
• Error Set Type
• Error Union Type
• Vectors
• opaque
• anyframe
• struct
• enum
• Enum Literals
• union
• Functions
@typeInfo
Type information of structs, unions, enums, and error sets has fields which are guaranteed to be in the
same order as appearance in the source file.
Type information of structs, unions, enums, and opaques has declarations, which are also guaranteed
to be in the same order as appearance in the source file.
@typeName
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.
@TypeOf
@TypeOf(���) type
@TypeOf is a special builtin function that takes any (non-zero) number of expressions as parameters
and returns the type of the result, using Peer Type Resolution.
The expressions are evaluated, however they are guaranteed to have no runtime side-effects:
test_TypeOf_builtin.zig
const std = @import("std");
const expect = std.testing.expect;
Shell
$ zig test test_TypeOf_builtin.zig
1/1 test_TypeOf_builtin.test.no runtime side effects���OK
All 1 tests passed.
@unionInit
This is the same thing as union initialization syntax, except that the field name is a comptime-known
value rather than an identifier token.
@Vector
Creates Vectors.
@volatileCast
@workGroupId
Returns the index of the work group in the current kernel invocation in dimension dimension .
@workGroupSize
Returns the number of work items that a work group has in dimension dimension .
@workItemId
Returns the index of the work item in the work group in dimension dimension . This function
returns values between 0 (inclusive) and @workGroupSize(dimension) (exclusive).
Build Mode
Zig has four build modes:
• Debug (default)
• ReleaseFast
• ReleaseSafe
• ReleaseSmall
build.zig
const std = @import("std");
-Doptimize=Debug
Optimizations off and safety on (default)
-Doptimize=ReleaseSafe
Optimizations on and safety on
-Doptimize=ReleaseFast
Optimizations on and safety off
-Doptimize=ReleaseSmall
Size optimizations on and safety off
Debug
Shell
$ zig build-exe example.zig
ReleaseFast
Shell
$ zig build-exe example.zig -O ReleaseFast
ReleaseSafe
Shell
$ zig build-exe example.zig -O ReleaseSafe
ReleaseSmall
Shell
$ zig build-exe example.zig -O ReleaseSmall
• Medium runtime performance
• Safety checks disabled
• Slow compilation speed
• Small binary size
• Reproducible build
See also:
• Compile Variables
• Zig Build System
• Illegal Behavior
• All Thread Local Variables are treated as regular Container Level Variables.
• The overhead of Async Functions becomes equivalent to function call overhead.
• The @import("builtin").single_threaded becomes true and therefore various
userland APIs which read this variable become more efficient. For example std.Mutex
becomes an empty data structure and all of its functions become no-ops.
Illegal Behavior
Many operations in Zig trigger what is known as "Illegal Behavior" (IB). If Illegal Behavior is detected at
compile-time, Zig emits a compile error and refuses to continue. Otherwise, when Illegal Behavior is
not caught at compile-time, it falls into one of two categories.
Some Illegal Behavior is safety-checked: this means that the compiler will insert "safety checks"
anywhere that the Illegal Behavior may occur at runtime, to determine whether it is about to happen. If
it is, the safety check "fails", which triggers a panic.
All other Illegal Behavior is unchecked, meaning the compiler is unable to insert safety checks for it. If
Unchecked Illegal Behavior is invoked at runtime, anything can happen: usually that will be some kind
of crash, but the optimizer is free to make Unchecked Illegal Behavior do anything, such as calling
arbitrary functions or clobbering arbitrary data. This is similar to the concept of "undefined behavior" in
some other languages. Note that Unchecked Illegal Behavior still always results in a compile error if
evaluated at comptime, because the Zig compiler is able to perform more sophisticated checks at
compile-time than at runtime.
Most Illegal Behavior is safety-checked. However, to facilitate optimizations, safety checks are
disabled by default in the ReleaseFast and ReleaseSmall optimization modes. Safety checks can also
be enabled or disabled on a per-block basis, overriding the default for the current optimization mode,
using @setRuntimeSafety. When safety checks are disabled, Safety-Checked Illegal Behavior behaves
like Unchecked Illegal Behavior; that is, any behavior may result from invoking it.
When a safety check fails, Zig's default panic handler crashes with a stack trace, like this:
test_illegal_behavior.zig
test "safety check" {
unreachable;
}
Shell
$ zig test test_illegal_behavior.zig
1/1 test_illegal_behavior.test.safety check���thread 3657076 panic: reached
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_illegal_beh
unreachable;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
if (test_fn.func()) |_| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/compiler/test_r
return mainTerminal();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
error: the following test command crashed:
/home/ci/actions-runner/_work/zig-bootstrap/out/zig-local-cache/o/64770b7aa5
At compile-time:
test_comptime_reaching_unreachable.zig
comptime {
assert(false);
}
fn assert(ok: bool) void {
if (!ok) unreachable; �� assertion failure
}
Shell
$ zig test test_comptime_reaching_unreachable.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_re
if (!ok) unreachable; �� assertion failure
^~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_re
assert(false);
~~~~~~^~~~~~~
At runtime:
runtime_reaching_unreachable.zig
const std = @import("std");
Shell
$ zig build-exe runtime_reaching_unreachable.zig
$ ./runtime_reaching_unreachable
thread 3656886 panic: reached unreachable code
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/debug.zig:5
if (!ok) unreachable; �� assertion failure
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_reaching
std.debug.assert(false);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_index_out_of_bounds.zig
comptime {
const array: [5]u8 = "hello".*;
const garbage = array[5];
_ = garbage;
}
Shell
$ zig test test_comptime_index_out_of_bounds.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const garbage = array[5];
^
At runtime:
runtime_index_out_of_bounds.zig
pub fn main() void {
const x = foo("hello");
_ = x;
}
Shell
$ zig build-exe runtime_index_out_of_bounds.zig
$ ./runtime_index_out_of_bounds
thread 3656233 panic: index out of bounds: index 5, len 5
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_index_ou
return x[5];
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_index_ou
const x = foo("hello");
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_invalid_cast.zig
comptime {
const value: i32 = -1;
const unsigned: u32 = @intCast(value);
_ = unsigned;
}
Shell
$ zig test test_comptime_invalid_cast.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const unsigned: u32 = @intCast(value);
^~~~~
At runtime:
runtime_invalid_cast.zig
const std = @import("std");
Shell
$ zig build-exe runtime_invalid_cast.zig
$ ./runtime_invalid_cast
thread 3655905 panic: integer does not fit in destination type
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const unsigned: u32 = @intCast(value);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
test_comptime_invalid_cast_truncate.zig
comptime {
const spartan_count: u16 = 300;
const byte: u8 = @intCast(spartan_count);
_ = byte;
}
Shell
$ zig test test_comptime_invalid_cast_truncate.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const byte: u8 = @intCast(spartan_count);
^~~~~~~~~~~~~
At runtime:
runtime_invalid_cast_truncate.zig
const std = @import("std");
Shell
$ zig build-exe runtime_invalid_cast_truncate.zig
$ ./runtime_invalid_cast_truncate
thread 3653423 panic: integer does not fit in destination type
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const byte: u8 = @intCast(spartan_count);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
Default Operations
• + (addition)
• - (subtraction)
• - (negation)
• * (multiplication)
• / (division)
• @divTrunc (division)
• @divFloor (division)
• @divExact (division)
test_comptime_overflow.zig
comptime {
var byte: u8 = 255;
byte += 1;
}
Shell
$ zig test test_comptime_overflow.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_ov
byte += 1;
~~~~~^~~~
At runtime:
runtime_overflow.zig
const std = @import("std");
Shell
$ zig build-exe runtime_overflow.zig
$ ./runtime_overflow
thread 3656280 panic: integer overflow
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_overflow
byte += 1;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
• @import("std").math.add
• @import("std").math.sub
• @import("std").math.mul
• @import("std").math.divTrunc
• @import("std").math.divFloor
• @import("std").math.divExact
• @import("std").math.shl
math_add.zig
const math = @import("std").math;
const print = @import("std").debug.print;
pub fn main() !void {
var byte: u8 = 255;
Shell
$ zig build-exe math_add.zig
$ ./math_add
unable to add one: Overflow
error: Overflow
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/math.zig:57
if (ov[1] �� 0) return error.Overflow;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/math_add.zig:8�9
return err;
^
These builtins return a tuple containing whether there was an overflow (as a u1 ) and the possibly
overflowed bits of the operation:
• @addWithOverflow
• @subWithOverflow
• @mulWithOverflow
• @shlWithOverflow
Example of @addWithOverflow:
addWithOverflow_builtin.zig
const print = @import("std").debug.print;
pub fn main() void {
const byte: u8 = 255;
Shell
$ zig build-exe addWithOverflow_builtin.zig
$ ./addWithOverflow_builtin
overflowed result: 9
Wrapping Operations
• +% (wraparound addition)
• -% (wraparound subtraction)
• -% (wraparound negation)
• *% (wraparound multiplication)
test_wraparound_semantics.zig
const std = @import("std");
const expect = std.testing.expect;
const minInt = std.math.minInt;
const maxInt = std.math.maxInt;
Shell
$ zig test test_wraparound_semantics.zig
1/1 test_wraparound_semantics.test.wraparound addition and subtraction���OK
All 1 tests passed.
At compile-time:
test_comptime_shlExact_overwlow.zig
comptime {
const x = @shlExact(@as(u8, 0b01010101), 2);
_ = x;
}
Shell
$ zig test test_comptime_shlExact_overwlow.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_sh
const x = @shlExact(@as(u8, 0b01010101), 2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At runtime:
runtime_shlExact_overflow.zig
const std = @import("std");
Shell
$ zig build-exe runtime_shlExact_overflow.zig
$ ./runtime_shlExact_overflow
thread 3653582 panic: left shift overflowed bits
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_shlExact
const y = @shlExact(x, 2);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_shrExact_overflow.zig
comptime {
const x = @shrExact(@as(u8, 0b10101010), 2);
_ = x;
}
Shell
$ zig test test_comptime_shrExact_overflow.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_sh
const x = @shrExact(@as(u8, 0b10101010), 2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At runtime:
runtime_shrExact_overflow.zig
const builtin = @import("builtin");
const std = @import("std");
pub fn main() void {
var x: u8 = 0b10101010; �� runtime-known
_ = &x;
const y = @shrExact(x, 2);
std.debug.print("value: {}\n", .{y});
Shell
$ zig build-exe runtime_shrExact_overflow.zig
$ ./runtime_shrExact_overflow
thread 3654479 panic: right shift overflowed bits
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_shrExact
const y = @shrExact(x, 2);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
Division by Zero
At compile-time:
test_comptime_division_by_zero.zig
comptime {
const a: i32 = 1;
const b: i32 = 0;
const c = a / b;
_ = c;
}
Shell
$ zig test test_comptime_division_by_zero.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_di
const c = a / b;
^
At runtime:
runtime_division_by_zero.zig
const std = @import("std");
Shell
$ zig build-exe runtime_division_by_zero.zig
$ ./runtime_division_by_zero
thread 3654715 panic: division by zero
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_division
const c = a / b;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_remainder_division_by_zero.zig
comptime {
const a: i32 = 10;
const b: i32 = 0;
const c = a % b;
_ = c;
}
Shell
$ zig test test_comptime_remainder_division_by_zero.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_re
const c = a % b;
^
At runtime:
runtime_remainder_division_by_zero.zig
const std = @import("std");
Shell
$ zig build-exe runtime_remainder_division_by_zero.zig
$ ./runtime_remainder_division_by_zero
thread 3656851 panic: division by zero
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_remainde
const c = a % b;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_divExact_remainder.zig
comptime {
const a: u32 = 10;
const b: u32 = 3;
const c = @divExact(a, b);
_ = c;
}
Shell
$ zig test test_comptime_divExact_remainder.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_di
const c = @divExact(a, b);
^~~~~~~~~~~~~~~
At runtime:
runtime_divExact_remainder.zig
const std = @import("std");
Shell
$ zig build-exe runtime_divExact_remainder.zig
$ ./runtime_divExact_remainder
thread 3655275 panic: exact division produced remainder
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_divExact
const c = @divExact(a, b);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_unwrap_null.zig
comptime {
const optional_number: ?i32 = null;
const number = optional_number��;
_ = number;
}
Shell
$ zig test test_comptime_unwrap_null.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_un
const number = optional_number��;
~~~~~~~~~~~~~~~^~
At runtime:
runtime_unwrap_null.zig
const std = @import("std");
Shell
$ zig build-exe runtime_unwrap_null.zig
$ ./runtime_unwrap_null
thread 3655127 panic: attempt to use null value
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_unwrap_n
const number = optional_number��;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
One way to avoid this crash is to test for null instead of assuming non-null, with the if expression:
testing_null_with_if.zig
const print = @import("std").debug.print;
pub fn main() void {
const optional_number: ?i32 = null;
if (optional_number) |number| {
print("got number: {}\n", .{number});
} else {
print("it's null\n", .{});
}
}
Shell
$ zig build-exe testing_null_with_if.zig
$ ./testing_null_with_if
it's null
See also:
• Optionals
At compile-time:
test_comptime_unwrap_error.zig
comptime {
const number = getNumberOrFail() catch unreachable;
_ = number;
}
fn getNumberOrFail() !i32 {
return error.UnableToReturnNumber;
}
Shell
$ zig test test_comptime_unwrap_error.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_un
const number = getNumberOrFail() catch unreachable;
^~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_un
return error.UnableToReturnNumber;
^~~~~~~~~~~~~~~~~~~~
At runtime:
runtime_unwrap_error.zig
const std = @import("std");
pub fn main() void {
const number = getNumberOrFail() catch unreachable;
std.debug.print("value: {}\n", .{number});
}
fn getNumberOrFail() !i32 {
return error.UnableToReturnNumber;
}
Shell
$ zig build-exe runtime_unwrap_error.zig
$ ./runtime_unwrap_error
thread 3656342 panic: attempt to unwrap error: UnableToReturnNumber
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_unwrap_e
return error.UnableToReturnNumber;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_unwrap_e
const number = getNumberOrFail() catch unreachable;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
One way to avoid this crash is to test for an error instead of assuming a successful result, with the if
expression:
testing_error_with_if.zig
const print = @import("std").debug.print;
if (result) |number| {
print("got number: {}\n", .{number});
} else |err| {
print("got error: {s}\n", .{@errorName(err)});
}
}
fn getNumberOrFail() !i32 {
return error.UnableToReturnNumber;
}
Shell
$ zig build-exe testing_error_with_if.zig
$ ./testing_error_with_if
got error: UnableToReturnNumber
See also:
• Errors
At compile-time:
test_comptime_invalid_error_code.zig
comptime {
const err = error.AnError;
const number = @intFromError(err) + 10;
const invalid_err = @errorFromInt(number);
_ = invalid_err;
}
Shell
$ zig test test_comptime_invalid_error_code.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const invalid_err = @errorFromInt(number);
^~~~~~
At runtime:
runtime_invalid_error_code.zig
const std = @import("std");
Shell
$ zig build-exe runtime_invalid_error_code.zig
$ ./runtime_invalid_error_code
thread 3653615 panic: invalid error code
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const invalid_err = @errorFromInt(number);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_invalid_enum_cast.zig
const Foo = enum {
a,
b,
c,
};
comptime {
const a: u2 = 3;
const b: Foo = @enumFromInt(a);
_ = b;
}
Shell
$ zig test test_comptime_invalid_enum_cast.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const b: Foo = @enumFromInt(a);
^~~~~~~~~~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const Foo = enum {
^~~~
At runtime:
runtime_invalid_enum_cast.zig
const std = @import("std");
const Foo = enum {
a,
b,
c,
};
Shell
$ zig build-exe runtime_invalid_enum_cast.zig
$ ./runtime_invalid_enum_cast
thread 3652960 panic: invalid enum value
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const b: Foo = @enumFromInt(a);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_invalid_error_set_cast.zig
const Set1 = error{
A,
B,
};
const Set2 = error{
A,
C,
};
comptime {
_ = @as(Set2, @errorCast(Set1.B));
}
Shell
$ zig test test_comptime_invalid_error_set_cast.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
_ = @as(Set2, @errorCast(Set1.B));
^~~~~~~~~~~~~~~~~~
At runtime:
runtime_invalid_error_set_cast.zig
const std = @import("std");
Shell
$ zig build-exe runtime_invalid_error_set_cast.zig
$ ./runtime_invalid_error_set_cast
thread 3656852 panic: invalid error code
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const x: Set2 = @errorCast(set1);
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
foo(Set1.B);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_incorrect_pointer_alignment.zig
comptime {
const ptr: *align(1) i32 = @ptrFromInt(0x1);
const aligned: *align(4) i32 = @alignCast(ptr);
_ = aligned;
}
Shell
$ zig test test_comptime_incorrect_pointer_alignment.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const aligned: *align(4) i32 = @alignCast(ptr);
^��
At runtime:
runtime_incorrect_pointer_alignment.zig
const mem = @import("std").mem;
pub fn main() !void {
var array align(4) = [_]u32{ 0x11111111, 0x11111111 };
const bytes = mem.sliceAsBytes(array[0��]);
if (foo(bytes) �� 0x11111111) return error.Wrong;
}
fn foo(bytes: []u8) u32 {
const slice4 = bytes[1��5];
const int_slice = mem.bytesAsSlice(u32, @as([]align(4) u8, @alignCast
return int_slice[0];
}
Shell
$ zig build-exe runtime_incorrect_pointer_alignment.zig
$ ./runtime_incorrect_pointer_alignment
thread 3656580 panic: incorrect alignment
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_incorrec
const int_slice = mem.bytesAsSlice(u32, @as([]align(4) u8, @alignCast(sl
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_incorrec
if (foo(bytes) �� 0x11111111) return error.Wrong;
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
const result = root.main() catch |err| {
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
At compile-time:
test_comptime_wrong_union_field_access.zig
comptime {
var f = Foo{ .int = 42 };
f.float = 12.34;
}
Shell
$ zig test test_comptime_wrong_union_field_access.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_wr
f.float = 12.34;
~^~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_wr
const Foo = union {
^~~~~
At runtime:
runtime_wrong_union_field_access.zig
const std = @import("std");
Shell
$ zig build-exe runtime_wrong_union_field_access.zig
$ ./runtime_wrong_union_field_access
thread 3654478 panic: access of union field 'float' while field 'int' is act
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_wrong_un
f.float = 12.34;
^
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_wrong_un
bar(&f);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
change_active_union_field.zig
const std = @import("std");
Shell
$ zig build-exe change_active_union_field.zig
$ ./change_active_union_field
value: 12.34
To change the active field of a union when a meaningful value for the field is not known, use undefined,
like this:
undefined_active_union_field.zig
const std = @import("std");
Shell
$ zig build-exe undefined_active_union_field.zig
$ ./undefined_active_union_field
value: 12.34
See also:
• union
• extern union
This happens when casting a float to an integer where the float has a value outside the integer type's
range.
At compile-time:
test_comptime_out_of_bounds_float_to_integer_cast.zig
comptime {
const float: f32 = 4294967296;
const int: i32 = @intFromFloat(float);
_ = int;
}
Shell
$ zig test test_comptime_out_of_bounds_float_to_integer_cast.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_ou
const int: i32 = @intFromFloat(float);
^~~~~
At runtime:
runtime_out_of_bounds_float_to_integer_cast.zig
pub fn main() void {
var float: f32 = 4294967296; �� runtime-known
_ = &float;
const int: i32 = @intFromFloat(float);
_ = int;
}
Shell
$ zig build-exe runtime_out_of_bounds_float_to_integer_cast.zig
$ ./runtime_out_of_bounds_float_to_integer_cast
thread 3654823 panic: integer part of floating point value out of bounds
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_out_of_b
const int: i32 = @intFromFloat(float);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
This happens when casting a pointer with the address 0 to a pointer which may not have the address 0.
For example, C Pointers, Optional Pointers, and allowzero pointers allow address zero, but normal
Pointers do not.
At compile-time:
test_comptime_invalid_null_pointer_cast.zig
comptime {
const opt_ptr: ?*i32 = null;
const ptr: *i32 = @ptrCast(opt_ptr);
_ = ptr;
}
Shell
$ zig test test_comptime_invalid_null_pointer_cast.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_comptime_in
const ptr: *i32 = @ptrCast(opt_ptr);
^~~~~~~
At runtime:
runtime_invalid_null_pointer_cast.zig
pub fn main() void {
var opt_ptr: ?*i32 = null;
_ = &opt_ptr;
const ptr: *i32 = @ptrCast(opt_ptr);
_ = ptr;
}
Shell
$ zig build-exe runtime_invalid_null_pointer_cast.zig
$ ./runtime_invalid_null_pointer_cast
thread 3655202 panic: cast causes pointer to be null
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/runtime_invalid_
const ptr: *i32 = @ptrCast(opt_ptr);
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:6
root.main();
^
/home/ci/actions-runner/_work/zig-bootstrap/out/host/lib/zig/std/start.zig:2
asm volatile (switch (native_arch) {
^
�������: 0x0 in ��� (���)
(process terminated by signal)
Memory
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:
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 std.heap.c_allocator . However, by convention, there is no default allocator in
Zig. Instead, functions which need to allocate accept an Allocator parameter. Likewise, data
structures such as std.ArrayList accept an Allocator parameter in their initialization
functions:
test_allocator.zig
const std = @import("std");
const Allocator = std.mem.Allocator;
const expect = std.testing.expect;
Shell
$ zig test test_allocator.zig
1/1 test_allocator.test.using an allocator���OK
All 1 tests passed.
In the above example, 100 bytes of stack memory are used to initialize a
FixedBufferAllocator , which is then passed to a function. As a convenience there is a global
FixedBufferAllocator available for quick tests at std.testing.allocator , which will
also perform basic leak detection.
Choosing an Allocator
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 Allocator as a parameter and allow
your library's users to decide what allocator to use.
2. Are you linking libc? In this case, std.heap.c_allocator is likely the right choice, at
least for your main allocator.
3. Need to use the same allocator in multiple threads? Use one of your choice wrapped around
std.heap.ThreadSafeAllocator
4. Is the maximum number of bytes that you will need bounded by a number known at comptime?
In this case, use std.heap.FixedBufferAllocator .
5. 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:
cli_allocation.zig
const std = @import("std");
Shell
$ zig build-exe cli_allocation.zig
$ ./cli_allocation
ptr=i32@7f4fcb46e010
When using this kind of allocator, there is no need to free anything manually. Everything gets
freed at once with the call to arena.deinit() .
6. 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 std.heap.ArenaAllocator 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 std.heap.FixedBufferAllocator can be used as a
further optimization.
7. Are you writing a test, and you want to make sure error.OutOfMemory is handled
correctly? In this case, use std.testing.FailingAllocator .
8. Are you writing a test? In this case, use std.testing.allocator .
9. 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 comptime struct of configuration options and
returns a type. Generally, you will set up one std.heap.GeneralPurposeAllocator in
your main function, and then pass it or sub-allocators around to various parts of your application.
10. You can also consider Implementing an Allocator.
String literals such as "hello" 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:
test_string_literal_to_slice.zig
fn foo(s: []u8) void {
_ = s;
}
Shell
$ zig test test_string_literal_to_slice.zig
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_string_lite
foo("hello");
^~~~~~~
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_string_lite
/home/ci/actions-runner/_work/zig-bootstrap/zig/doc/langref/test_string_lite
fn foo(s: []u8) void {
^~~~
test_string_literal_to_const_slice.zig
fn foo(s: []const u8) void {
_ = s;
}
Shell
$ zig test test_string_literal_to_const_slice.zig
1/1 test_string_literal_to_const_slice.test.string literal to constant slice
All 1 tests passed.
Just like string literals, const declarations, when the value is known at comptime, are stored in the
global constant data section. Also Compile Time Variables are stored in the global constant data
section.
var declarations inside functions are stored in the function's stack frame. Once a function returns,
any Pointers to variables in the function's stack frame become invalid references, and dereferencing
them becomes unchecked Illegal Behavior.
var declarations at the top level or in struct declarations are stored in the global data section.
Implementing an Allocator
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
allocFn and a resizeFn .
There are many example allocators to look at for inspiration. Look at std/heap.zig and
std.heap.GeneralPurposeAllocator .
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, error.OutOfMemory 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:
Recursion
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 pointer is not accessed when the memory
pointed to is no longer available. Note that a slice 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 Allocator parameter.
Sometimes the lifetime of a pointer may be more complicated. For example, the
std.ArrayList(T).items 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 Illegal Behavior occur).
Compile Variables
Compile variables are accessible by importing the "builtin" 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.
compile_variables.zig
const builtin = @import("builtin");
const separator = if (builtin.os.tag �� .windows) '\\' else '/';
@import("builtin")
const std = @import("std");
��� Zig version. When writing code that supports multiple versions of Zig, p
��� feature detection (i.e. with `@hasDecl` or `@hasField`) over version che
pub const zig_version = std.SemanticVersion.parse(zig_version_string)
pub const zig_version_string = "0.15.0-dev.1228+6dbcc3bd5";
pub const zig_backend = std.builtin.CompilerBackend.stage2_x86_64;
See also:
• Build Mode
Compilation Model
A Zig compilation is separated into modules. Each module is a collection of Zig source files, one of
which is the module's root source file. Each module can depend on any number of other modules,
forming a directed graph (dependency loops between modules are allowed). If module A depends on
module B, then any Zig source file in module A can import the root source file of module B using
@import with the module's name. In essence, a module acts as an alias to import a Zig source file
(which might exist in a completely separate part of the filesystem).
A simple Zig program compiled with zig build-exe has two key modules: the one containing
your code, known as the "main" or "root" module, and the standard library. Your module depends on
the standard library module under the name "std", which is what allows you to write
@import("std") ! In fact, every single module in a Zig compilation — including the standard
library itself — implicitly depends on the standard library module under the name "std".
The "root module" (the one provided by you in the zig build-exe example) has a special
property. Like the standard library, it is implicitly made available to all modules (including itself), this
time under the name "root". So, @import("root") will always be equivalent to @import of
your "main" source file (often, but not necessarily, named main.zig ).
Every Zig source file is implicitly a struct declaration; you can imagine that the file's contents are
literally surrounded by struct { ��� } . This means that as well as declarations, the top level of
a file is permitted to contain fields:
TopLevelFields.zig
��! Because this file contains fields, it is a type which is intended to be
��! is named in TitleCase instead of snake_case by convention.
foo: u32,
bar: u64,
��� `@This()` can be used to refer to this struct type. In files with fields
��� name the type here, so it can be easily referenced by other declarations
const TopLevelFields = @This();
Such files can be instantiated just like any other struct type. A file's "root struct type" can be
referred to within that file using @This.
That's it! Those rules define how Zig files and declarations are discovered. All that remains is to
understand where this process starts.
The answer to that is the root of the standard library: every Zig compilation begins by analyzing the file
lib/std/std.zig . This file contains a comptime declaration which imports lib/std/
start.zig , and that file in turn uses @import("root") to reference the "root module"; so, the
file you provide as your main module's root source file is effectively also a root, because the standard
library will always reference it.
It is often desirable to make sure that certain declarations — particularly test or export
declarations — are discovered. Based on the above rules, a common strategy for this is to use
@import within a comptime or test block:
force_file_discovery.zig
comptime {
�� This will ensure that the file 'api.zig' is always discovered (as lon
�� It is useful if 'api.zig' contains important exported declarations.
_ = @import("api.zig");
test {
�� This will ensure that the file 'tests.zig' is always discovered (as l
�� if this compilation is a test. It is useful if 'tests.zig' contains t
_ = @import("tests.zig");
�� We could also have a file which contains tests we only want to run de
�� In that case, we can use an `if` statement here:
if (builtin.os.tag �� .windows) {
_ = @import("windows_tests.zig");
}
}
Because the root module's root source file is always accessible using @import("root") , is is
sometimes used by libraries — including the Zig Standard Library — as a place for the program to
expose some "global" information to that library. The Zig Standard Library will look for several
declarations in this file.
Entry Point
When building an executable, the most important thing to be looked up in this file is the program's
entry point. Most commonly, this is a function named main , which std.start will call just after
performing important initialization work.
Alternatively, the presence of a declaration named _start (for instance, pub const _start
= {}; ) will disable the default std.start logic, allowing your root source file to export a low-
level entry point as needed.
entry_point.zig
��� `std.start` imports this file using `@import("root")`, and uses this dec
��� user-provided entry point. It can return any of the following types:
��� * `void`
��� * `E!void`, for any error set `E�
��� * `u8`
��� * `E!u8`, for any error set `E�
��� Returning a `void` value from this function will exit with code 0.
��� Returning a `u8` value from this function will exit with the given statu
��� Returning an error value from this function will print an Error Return T
pub fn main() void {
std.debug.print("Hello, World!\n", .{});
}
Shell
$ zig build-exe entry_point.zig
$ ./entry_point
Hello, World!
If the Zig compilation links libc, the main function can optionally be an export fn which
matches the signature of the C main function:
libc_export_entry_point.zig
pub export fn main(argc: c_int, argv: [*]const [*:0]const u8) c_int {
const args = argv[0��@intCast(argc)];
std.debug.print("Hello! argv[0] is '{s}'\n", .{args[0]});
return 0;
}
Shell
$ zig build-exe libc_export_entry_point.zig -lc
$ ./libc_export_entry_point
Hello! argv[0] is './libc_export_entry_point'
std.start may also use other entry point declarations in certain situations, such as wWinMain
or EfiMain . Refer to the lib/std/start.zig logic for details of these declarations.
std_options.zig
��� The presence of this declaration allows the program to override certain
��� For a full list of available options, see the documentation for `std.Opt
pub const std_options: std.Options = .{
�� By default, in safe build modes, the standard library will attach a s
�� print a helpful stack trace if a segmentation fault occurs. Here, we
�� it in unsafe build modes.
.enable_segfault_handler = true,
�� This is the logging function used by `std.log`.
.logFn = myLogFn,
};
fn myLogFn(
comptime level: std.log.Level,
comptime scope: @Type(.enum_literal),
comptime format: []const u8,
args: anytype,
) void {
�� We could do anything we want here!
�� ���but actually, let's just call the default implementation.
std.log.defaultLog(level, scope, format, args);
}
Panic Handler
The Zig Standard Library looks for a declaration named panic in the root module's root source file. If
present, it is expected to be a namespace (container type) with declarations providing different panic
handlers.
Overriding how the panic handler actually outputs messages, but keeping the formatted safety panics
which are enabled by default, can be easily achieved with std.debug.FullPanic :
panic_handler.zig
pub fn main() void {
@setRuntimeSafety(true);
var x: u8 = 255;
�� Let's overflow this integer!
x += 1;
}
Shell
$ zig build-exe panic_handler.zig
$ ./panic_handler
Panic! integer overflow
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.
For the time being, the build system documentation is hosted externally: Build System Documentation
C
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.
C Type Primitives
These have guaranteed C ABI compatibility and can be used like any other type.
• c_char
• c_short
• c_ushort
• c_int
• c_uint
• c_long
• c_ulong
• c_longlong
• c_ulonglong
• c_longdouble
See also:
• Primitive Types
The @cImport builtin function can be used to directly import symbols from .h files:
cImport_builtin.zig
const c = @cImport({
�� See https:��github.com/ziglang/zig/issues/515
@cDefine("_NO_CRT_STDIO_INLINE", "1");
@cInclude("stdio.h");
});
pub fn main() void {
_ = c.printf("hello\n");
}
Shell
$ zig build-exe cImport_builtin.zig -lc
$ ./cImport_builtin
hello
@cImport Expression
const builtin = @import("builtin");
const c = @cImport({
@cDefine("NDEBUG", builtin.mode �� .ReleaseFast);
if (something) {
@cDefine("_GNU_SOURCE", {});
}
@cInclude("stdlib.h");
if (something) {
@cUndef("_GNU_SOURCE");
}
@cInclude("soundio.h");
});
See also:
• @cImport
• @cInclude
• @cDefine
• @cUndef
• @import
C Translation CLI
Zig's C translation capability is available as a CLI tool via zig translate-c. It requires a single
filename as an argument. It may also take a set of optional flags that are forwarded to clang. It writes
the translated file to stdout.
• -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 target triple for the translated Zig code. If no target is specified, the current host
target will be used.
Using -target and -cflags
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.
varytarget.h
long FOO = ��LONG_MAX��;
Shell
$ zig translate-c -target thumb-freestanding-gnueabihf varytarget.h|grep FOO
pub export var FOO: c_long = 2147483647;
$ zig translate-c -target x86_64-macos-gnu varytarget.h|grep FOO
pub export var FOO: c_long = 9223372036854775807;
varycflags.h
enum FOO { BAR };
int do_something(enum FOO foo);
Shell
$ zig translate-c varycflags.h|grep -B1 do_something
pub const enum_FOO = c_uint;
pub extern fn do_something(foo: enum_FOO) c_int;
$ zig translate-c -cflags -fshort-enums �� varycflags.h|grep -B1 do_somethin
pub const enum_FOO = u8;
pub extern fn do_something(foo: enum_FOO) c_int;
@cImport vs translate-c
@cImport and zig translate-c use the same underlying C translation functionality, so on a
technical level they are equivalent. In practice, @cImport 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 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 anytype parameters in function-like macros to more specific types; changing [*c]T
pointers to [*]T or *T pointers for improved type safety; and enabling or disabling runtime safety
within specific functions.
See also:
• Targets
• C Type Primitives
• Pointers
• C Pointers
• Import from C Header File
• @cInclude
• @cImport
• @setRuntimeSafety
C Translation Caching
The C translation feature (whether used via zig translate-c or @cImport ) 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 @cImport , use the ��
verbose-cimport flag:
verbose_cimport_flag.zig
const c = @cImport({
@cDefine("_NO_CRT_STDIO_INLINE", "1");
@cInclude("stdio.h");
});
pub fn main() void {
_ = c;
}
Shell
$ zig build-exe verbose_cimport_flag.zig -lc ��verbose-cimport
info(compilation): C import source: /home/ci/actions-runner/_work/zig-bootst
info(compilation): C import .d file: /home/ci/actions-runner/_work/zig-boots
$ ./verbose_cimport_flag
cimport.h contains the file to translate (constructed from calls to @cInclude , @cDefine ,
and @cUndef ), cimport.h.d is the list of file dependencies, and cimport.zig contains the
translated output.
See also:
Translation failures
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 - opaque, extern, and @compileError . C structs and unions
that cannot be translated correctly will be translated as opaque{} . Functions that contain opaque
types or code constructs that cannot be translated will be demoted to extern 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.
@compileError 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.
See also:
• opaque
• extern
• @compileError
C Macros
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 demoted to @compileError . 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.
macro.c
#define MAKELOCAL(NAME, INIT) int NAME = INIT
int foo(void) {
MAKELOCAL(a, 1);
MAKELOCAL(b, 2);
return a + b;
}
Shell
$ zig translate-c macro.c > macro.zig
macro.zig
pub export fn foo() c_int {
var a: c_int = 1;
_ = &a;
var b: c_int = 2;
_ = &b;
return a + b;
}
pub const MAKELOCAL = @compileError("unable to translate C expr: unexpected
Note that foo was translated correctly despite using a non-translatable macro. MAKELOCAL was
demoted to @compileError since it cannot be expressed as a Zig function; this simply means that
you cannot directly use MAKELOCAL from Zig.
See also:
• @compileError
C Pointers
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 ( *T ) or many-item pointers ( [*]T ). C pointers are a compromise so that Zig code can
utilize translated header files directly.
[*c]T - C pointer.
• Supports all the syntax of the other two pointer types ( *T ) and ( [*]T ).
• Coerces to other pointer types, as well as Optional Pointers. When a C pointer is coerced to a
non-optional pointer, safety-checked Illegal Behavior occurs if the address is 0.
• Allows address 0. On non-freestanding targets, dereferencing address 0 is safety-checked Illegal
Behavior. Optional C pointers introduce another bit to keep track of null, just like ?usize .
Note that creating an optional C pointer is unnecessary as one can use normal Optional Pointers.
• Supports Type Coercion to and from integers.
• Supports comparison with integers.
• Does not support Zig-only pointer attributes such as alignment. Use normal Pointers please!
When a C pointer is pointing to a single struct (not an array), dereference the C pointer to access the
struct's fields or member data. That syntax looks like this:
ptr_to_struct.*.struct_member
C Variadic Functions
test_variadic_function.zig
const std = @import("std");
const testing = std.testing;
Shell
$ zig test test_variadic_function.zig -lc
1/1 test_variadic_function.test.variadic function���OK
All 1 tests passed.
Hello, world!
Variadic functions can be implemented using @cVaStart, @cVaEnd, @cVaArg and @cVaCopy.
test_defining_variadic_function.zig
const std = @import("std");
const testing = std.testing;
const builtin = @import("builtin");
Shell
$ zig test test_defining_variadic_function.zig
1/1 test_defining_variadic_function.test.defining a variadic function���OK
All 1 tests passed.
Exporting a C Library
One of the primary use cases for Zig is exporting a library with the C ABI for other programming
languages to call into. The export keyword in front of functions, variables, and types causes them
to be part of the library API:
mathtest.zig
export fn add(a: i32, b: i32) i32 {
return a + b;
}
Shell
$ zig build-lib mathtest.zig
Shell
$ zig build-lib mathtest.zig -dynamic
test.c
�� This header is generated by zig from mathtest.zig
#include "mathtest.h"
#include <stdio.h>
build_c.zig
const std = @import("std");
b.default_step.dependOn(&exe.step);
Shell
$ zig build test
1379
See also:
• export
You can mix Zig object files with any other object files that respect the C ABI. Example:
base64.zig
const base64 = @import("std").base64;
export fn decode_base_64(
dest_ptr: [*]u8,
dest_len: usize,
source_ptr: [*]const u8,
source_len: usize,
) usize {
const src = source_ptr[0��source_len];
const dest = dest_ptr[0��dest_len];
const base64_decoder = base64.standard.Decoder;
const decoded_size = base64_decoder.calcSizeForSlice(src) catch unreacha
base64_decoder.decode(dest[0��decoded_size], src) catch unreachable
return decoded_size;
}
test.c
�� This header is generated by zig from base64.zig
#include "base64.h"
#include <string.h>
#include <stdio.h>
return 0;
}
build_object.zig
const std = @import("std");
Shell
$ zig build
$ ./zig-out/bin/test
all your base are belong to us
See also:
• Targets
• Zig Build System
WebAssembly
Zig supports building for WebAssembly out of the box.
Freestanding
For host environments like the web browser and nodejs, build as an executable using the freestanding
OS target. Here's an example of running Zig code compiled to WebAssembly with nodejs.
math.zig
extern fn print(i32) void;
Shell
$ zig build-exe math.zig -target wasm32-freestanding -fno-entry ��export=add
test.js
const fs = require('fs');
const source = fs.readFileSync("./math.wasm");
const typedArray = new Uint8Array(source);
WebAssembly.instantiate(typedArray, {
env: {
print: (result) �� { console.log(`The result is ${result}`); }
��).then(result �� {
const add = result.instance.exports.add;
add(1, 2);
});
Shell
$ node test.js
The result is 3
WASI
Zig's support for WebAssembly System Interface (WASI) is under active development. Example of
using the standard library and reading command line arguments:
wasi_args.zig
const std = @import("std");
Shell
$ zig build-exe wasi_args.zig -target wasm32-wasi
Shell
$ wasmtime wasi_args.wasm 123 hello
0: wasi_args.wasm
1: 123
2: hello
A more interesting example would be extracting the list of preopens from the runtime. This is now
supported in the standard library via std.fs.wasi.Preopens :
wasi_preopens.zig
const std = @import("std");
const fs = std.fs;
Shell
$ zig build-exe wasi_preopens.zig -target wasm32-wasi
Shell
$ wasmtime ��dir=. wasi_preopens.wasm
0: stdin
1: stdout
2: stderr
3: .
Targets
Target refers to the computer that will be used to run an executable. It is composed of the CPU
architecture, the set of enabled CPU features, operating system, minimum and maximum operating
system version, ABI, and ABI version.
Zig is a general-purpose programming language which means that it is designed to generate optimal
code for a large set of targets. The command zig targets provides information about all of the
targets the compiler is aware of.
When no target option is provided to the compiler, the default choice is to target the host computer,
meaning that the resulting executable will be unsuitable for copying to a different computer. In order to
copy an executable to another computer, the compiler needs to know about the target requirements
via the -target option.
The Zig Standard Library ( @import("std") ) has cross-platform abstractions, making the same
source code viable on many targets. Some code is more portable than other code. In general, Zig code
is extremely portable compared to other programming languages.
Each platform requires its own implementations to make Zig's cross-platform abstractions work. These
implementations are at various degrees of completion. Each tagged release of the compiler comes with
release notes that provide the full support table for each target.
Style Guide
These coding conventions are not enforced by the compiler, but they are shipped in this documentation
along with the compiler in order to provide a point of reference, should anyone wish to point to an
authority on agreed upon Zig coding style.
• Value
• Data
• Context
• Manager
• utils, misc, or somebody's initials
Everything is a value, all types are data, everything is context, all logic manages state. Nothing is
communicated by using a word that applies to all types.
Every declaration is assigned a fully qualified namespace by the compiler, creating a tree structure.
Choose names based on the fully-qualified namespace, and avoid redundant name segments.
redundant_fqn.zig
const std = @import("std");
Shell
$ zig build-exe redundant_fqn.zig
$ ./redundant_fqn
redundant_fqn.json.JsonValue
In this example, "json" is repeated in the fully-qualified namespace. The solution is to delete Json
from JsonValue . In this example we have an empty struct named json but remember that files
also act as part of the fully-qualified namespace.
This example is an exception to the rule specified in Avoid Redundancy in Names. The meaning of the
type has been reduced to its core: it is a json value. The name cannot be any more specific without
being incorrect.
Whitespace
• 4 space indentation
• Open braces on same line, unless you need to wrap.
• If a list of things is longer than 2, put each item on its own line and exercise the ability to put an
extra comma at the end.
• Line length: aim for 100; use common sense.
Names
Acronyms, initialisms, proper nouns, or any other word that has capitalization rules in written English
are subject to naming conventions just like any other word. Even acronyms that are only 2 letters long
are subject to these conventions.
File names fall into two categories: types and namespaces. If the file (implicitly a struct) has top level
fields, it should be named like any other struct with fields using TitleCase . Otherwise, it should
use snake_case . Directory names should be snake_case .
These are general rules of thumb; if it makes sense to do something different, do what makes sense.
For example, if there is an established convention such as ENOENT , follow the established
convention.
Examples
style_example.zig
const namespace_name = @import("dir_name/file_name.zig");
const TypeName = @import("dir_name/TypeName.zig");
var global_var: i32 = undefined;
const const_name = 42;
const primitive_type_alias = f32;
const string_alias = []u8;
�� The word XML loses its casing when used in Zig identifiers.
const xml_document =
\\<?xml version="1.0" encoding="UTF-8"?>
\\<document>
\\��document>
;
const XmlParser = struct {
field: i32,
};
�� The initials BE (Big Endian) are just another word in Zig identifier name
fn readU32Be() u32 {}
Source Encoding
Zig source code is encoded in UTF-8. An invalid UTF-8 byte sequence results in a compile error.
Throughout all zig source code (including in comments), some code points are never allowed:
• Ascii control characters, except for U+000a (LF), U+000d (CR), and U+0009 (HT): U+0000 -
U+0008, U+000b - U+000c, U+000e - U+0001f, U+007f.
• Non-Ascii Unicode line endings: U+0085 (NEL), U+2028 (LS), U+2029 (PS).
LF (byte value 0x0a, code point U+000a, '\n' ) is the line terminator in Zig source code. This byte
value terminates every line of zig source code except the last line of the file. It is recommended that
non-empty source files end with an empty line, which means the last byte would be 0x0a (LF).
Each LF may be immediately preceded by a single CR (byte value 0x0d, code point U+000d, '\r' ) to
form a Windows style line ending, but this is discouraged. Note that in multiline strings, CRLF
sequences will be encoded as LF when compiled into a zig program. A CR in any other context is not
allowed.
HT hard tabs (byte value 0x09, code point U+0009, '\t' ) are interchangeable with SP spaces (byte
value 0x20, code point U+0020, ' ' ) as a token separator, but use of hard tabs is discouraged. See
Grammar.
For compatibility with other tools, the compiler ignores a UTF-8-encoded byte order mark (U+FEFF) if it
is the first Unicode code point in the source text. A byte order mark is not allowed anywhere else in the
source.
Note that running zig fmt on a source file will implement all recommendations mentioned here.
Note that a tool reading Zig source code can make assumptions if the source code is assumed to be
correct Zig code. For example, when identifying the ends of lines, a tool can use a naive search such as
/\n/ , or an advanced search such as /\r\n?|[\n\u0085\u2028\u2029]/ , and in either
case line endings will be correctly identified. For another example, when identifying the whitespace
before the first token on a line, a tool can either use a naive search such as /[ \t]/ , or an
advanced search such as /\s/ , and in either case whitespace will be correctly identified.
Keyword Reference
Keyword Description
align can be used to specify the alignment of a pointer. It can also be used
after a variable or function declaration to specify the alignment of pointers to
that variable or function.
align
See also Alignment
asm begins an inline assembly expression. This allows for directly controlling
the machine code generated on compilation.
asm
See also Assembly
Keyword Description
break can be used with a block label to return a value from the block. It can
also be used to exit a loop before iteration completes naturally.
break
See also Blocks, while, for
continue can be used in a loop to jump back to the beginning of the loop.
defer will execute an expression when control flow leaves the current
block.
defer
See also defer
Keyword Description
If used after an if expression, the else branch will be executed if the test value
returns false, null, or an error.
If used within a switch expression, the else branch will be executed if the test
else
value matches no other cases.
If used after a loop expression, the else branch will be executed if the loop
finishes without breaking.
errdefer will execute an expression when control flow leaves the current
block if the function returns an error, the errdefer expression can capture the
unwrapped value.
errdefer
See also errdefer
fn declares a function.
A for expression can be used to iterate over the elements of a slice, array,
or tuple.
for
See also for
inline can be used to label a loop expression such that it will be unrolled
at compile time. It can also be used to force a function to be inlined at all call
sites.
inline
See also inline while, inline for, Functions
Code inside a nosuspend scope does not cause the enclosing function to
become an async function.
The packed keyword before a struct definition changes the struct's in-
memory layout to the guaranteed packed layout.
packed
See also packed struct
The pub in front of a top level declaration makes the declaration available to
reference from a different file than the one it is declared in.
pub
See also import
Keyword Description
resume will continue execution of a function frame after the point the
resume
function was suspended.
suspend will cause control flow to return to the call site or resumer of the
function. suspend can also be used before a block within a function, to
suspend
allow the function access to its frame before control flow returns to the call
site.
The test keyword can be used to denote a top-level block of code used to
make sure behavior meets expectations.
test
See also Zig Test
unreachable can be used to assert that control flow will never happen
upon a particular location. Depending on the build mode, unreachable
may emit a panic.
Appendix
Containers
A container in Zig is any syntactical construct that acts as a namespace to hold variable and function
declarations. Containers are also type definitions which can be instantiated. Structs, enums, unions,
opaques, and even Zig source files themselves are containers.
Although containers (except Zig source files) use curly braces to surround their definition, they should
not be confused with blocks or functions. Containers do not contain statements.
Grammar
grammar.y
Root �� skip container_doc_comment? ContainerMembers eof
Decl
�� (KEYWORD_export / KEYWORD_extern STRINGLITERALSINGLE? / KEYWORD_inlin
/ (KEYWORD_export / KEYWORD_extern STRINGLITERALSINGLE?)? KEYWORD_threa
ComptimeStatement
�� BlockExpr
/ VarDeclExprStatement
IfStatement
�� IfPrefix BlockExpr ( KEYWORD_else Payload? Statement )?
/ IfPrefix AssignExpr ( SEMICOLON / KEYWORD_else Payload? Statement )
ForStatement
�� ForPrefix BlockExpr ( KEYWORD_else Statement )?
/ ForPrefix AssignExpr ( SEMICOLON / KEYWORD_else Statement )
WhileStatement
�� WhilePrefix BlockExpr ( KEYWORD_else Payload? Statement )?
/ WhilePrefix AssignExpr ( SEMICOLON / KEYWORD_else Payload? Statement
BlockExprStatement
�� BlockExpr
/ AssignExpr SEMICOLON
Expr �� BoolOrExpr
PrimaryExpr
�� AsmExpr
/ IfExpr
/ KEYWORD_break BreakLabel? Expr?
/ KEYWORD_comptime Expr
/ KEYWORD_nosuspend Expr
/ KEYWORD_continue BreakLabel?
/ KEYWORD_resume Expr
/ KEYWORD_return Expr?
/ BlockLabel? LoopExpr
/ Block
/ CurlySuffixExpr
InitList
�� LBRACE FieldInit (COMMA FieldInit)* COMMA? RBRACE
/ LBRACE Expr (COMMA Expr)* COMMA? RBRACE
/ LBRACE RBRACE
SuffixExpr
�� PrimaryTypeExpr (SuffixOp / FnCallArguments)*
PrimaryTypeExpr
�� BUILTINIDENTIFIER FnCallArguments
/ CHAR_LITERAL
/ ContainerDecl
/ DOT IDENTIFIER
/ DOT InitList
/ ErrorSetDecl
/ FLOAT
/ FnProto
/ GroupedExpr
/ LabeledTypeExpr
/ IDENTIFIER
/ IfTypeExpr
/ INTEGER
/ KEYWORD_comptime TypeExpr
/ KEYWORD_error DOT IDENTIFIER
/ KEYWORD_anyframe
/ KEYWORD_unreachable
/ STRINGLITERAL
/ SwitchExpr
LabeledTypeExpr
�� BlockLabel Block
/ BlockLabel? LoopTypeExpr
# Fn specific
CallConv �� KEYWORD_callconv LPAREN Expr RPAREN
ParamDecl
�� doc_comment? (KEYWORD_noalias / KEYWORD_comptime)? (IDENTIFIER COLON)
/ DOT3
ParamType
�� KEYWORD_anytype
/ TypeExpr
# Payloads
Payload �� PIPE IDENTIFIER PIPE
# Switch specific
SwitchProng �� KEYWORD_inline? SwitchCase EQUALRARROW PtrIndexPayload? Singl
SwitchCase
�� SwitchItem (COMMA SwitchItem)* COMMA?
/ KEYWORD_else
# For specific
ForArgumentsList �� ForItem (COMMA ForItem)* COMMA?
ForItem �� Expr (DOT2 Expr?)?
# Operators
AssignOp
�� ASTERISKEQUAL
/ ASTERISKPIPEEQUAL
/ SLASHEQUAL
/ PERCENTEQUAL
/ PLUSEQUAL
/ PLUSPIPEEQUAL
/ MINUSEQUAL
/ MINUSPIPEEQUAL
/ LARROW2EQUAL
/ LARROW2PIPEEQUAL
/ RARROW2EQUAL
/ AMPERSANDEQUAL
/ CARETEQUAL
/ PIPEEQUAL
/ ASTERISKPERCENTEQUAL
/ PLUSPERCENTEQUAL
/ MINUSPERCENTEQUAL
/ EQUAL
CompareOp
�� EQUALEQUAL
/ EXCLAMATIONMARKEQUAL
/ LARROW
/ RARROW
/ LARROWEQUAL
/ RARROWEQUAL
BitwiseOp
�� AMPERSAND
/ CARET
/ PIPE
/ KEYWORD_orelse
/ KEYWORD_catch Payload?
BitShiftOp
�� LARROW2
/ RARROW2
/ LARROW2PIPE
AdditionOp
�� PLUS
/ MINUS
/ PLUS2
/ PLUSPERCENT
/ MINUSPERCENT
/ PLUSPIPE
/ MINUSPIPE
MultiplyOp
�� PIPE2
/ ASTERISK
/ SLASH
/ PERCENT
/ ASTERISK2
/ ASTERISKPERCENT
/ ASTERISKPIPE
PrefixOp
�� EXCLAMATIONMARK
/ MINUS
/ TILDE
/ MINUSPERCENT
/ AMPERSAND
/ KEYWORD_try
PrefixTypeOp
�� QUESTIONMARK
/ KEYWORD_anyframe MINUSRARROW
/ SliceTypeStart (ByteAlign / AddrSpace / KEYWORD_const / KEYWORD_volat
/ PtrTypeStart (AddrSpace / KEYWORD_align LPAREN Expr (COLON Expr COLON
/ ArrayTypeStart
SuffixOp
�� LBRACKET Expr (DOT2 (Expr? (COLON Expr)?)?)? RBRACKET
/ DOT IDENTIFIER
/ DOTASTERISK
/ DOTQUESTIONMARK
# Ptr specific
SliceTypeStart �� LBRACKET (COLON Expr)? RBRACKET
PtrTypeStart
�� ASTERISK
/ ASTERISK2
/ LBRACKET ASTERISK (LETTERC / COLON Expr)? RBRACKET
# ContainerDecl specific
ContainerDeclAuto �� ContainerDeclType LBRACE container_doc_comment? Contain
ContainerDeclType
�� KEYWORD_struct (LPAREN Expr RPAREN)?
/ KEYWORD_opaque
/ KEYWORD_enum (LPAREN Expr RPAREN)?
/ KEYWORD_union (LPAREN (KEYWORD_enum (LPAREN Expr RPAREN)? / Expr) RPA
# Alignment
ByteAlign �� KEYWORD_align LPAREN Expr RPAREN
# Lists
IdentifierList �� (doc_comment? IDENTIFIER COMMA)* (doc_comment? IDENTIFIER)
ox80_oxBF �� [\200-\277]
oxF4 �� '\364'
ox80_ox8F �� [\200-\217]
oxF1_oxF3 �� [\361-\363]
oxF0 �� '\360'
ox90_0xBF �� [\220-\277]
oxEE_oxEF �� [\356-\357]
oxED �� '\355'
ox80_ox9F �� [\200-\237]
oxE1_oxEC �� [\341-\354]
oxE0 �� '\340'
oxA0_oxBF �� [\240-\277]
oxC2_oxDF �� [\302-\337]
# From https:��lemire.me/blog/2018/05/09/how-quickly-can-you-check-that-a-st
# First Byte Second Byte Third Byte Fourth Byte
# [0x00,0x7F]
# [0xC2,0xDF] [0x80,0xBF]
# 0xE0 [0xA0,0xBF] [0x80,0xBF]
# [0xE1,0xEC] [0x80,0xBF] [0x80,0xBF]
# 0xED [0x80,0x9F] [0x80,0xBF]
# [0xEE,0xEF] [0x80,0xBF] [0x80,0xBF]
# 0xF0 [0x90,0xBF] [0x80,0xBF] [0x80,0xBF]
# [0xF1,0xF3] [0x80,0xBF] [0x80,0xBF] [0x80,0xBF]
# 0xF4 [0x80,0x8F] [0x80,0xBF] [0x80,0xBF]
mb_utf8_literal ��
oxF4 ox80_ox8F ox80_oxBF ox80_oxBF
/ oxF1_oxF3 ox80_oxBF ox80_oxBF ox80_oxBF
/ oxF0 ox90_0xBF ox80_oxBF ox80_oxBF
/ oxEE_oxEF ox80_oxBF ox80_oxBF
/ oxED ox80_ox9F ox80_oxBF
/ oxE1_oxEC ox80_oxBF ox80_oxBF
/ oxE0 oxA0_oxBF ox80_oxBF
/ oxC2_oxDF ox80_oxBF
ascii_char_not_nl_slash_squote �� [\000-\011\013-\046\050-\133\135-\177]
char_escape
�� "\\x" hex hex
/ "\\u{" hex+ "}"
/ "\\" [nr\\t'"]
char_char
�� mb_utf8_literal
/ char_escape
/ ascii_char_not_nl_slash_squote
string_char
�� char_escape
/ [^\\"\n]
Zen