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.
The Zig code sample above demonstrates one way to create a program that will output: Hello, world!.
The code sample shows the contents of a file named hello.zig. Files storing Zig
source code are UTF-8 encoded text files. The files storing
Zig source code are usually named with the .zig extension.
Following the hello.zig Zig code sample, the Zig Build System is used
to build an executable program from the hello.zig source code. Then, the
hello program is executed showing its output Hello, world!. The
lines beginning with $ represent command line prompts and a command.
Everything else is program output.
The code sample begins by adding the Zig Standard Library to the build using the @import builtin function.
The @import("std") function call creates a structure that represents the Zig Standard Library.
The code then declares a
constant identifier, named std, that gives access the features of the Zig Standard Library.
Next, a public function, pubfn, named main
is declared. The main function is necessary because it tells the Zig compiler where the start of
the program exists. Programs designed to be executed will need a pubfnmain function.
A function is a block of any number of statements and expressions that, as a whole, perform a task.
Functions may or may not return data after they are done performing their task. If a function
cannot perform its task, it might return an error. Zig makes all of this explicit.
In the hello.zig code sample, the main function is declared
with the !void return type. This return type is known as an Error Union Type.
This syntax tells the Zig compiler that the function will either return an
error or a value. An error union type combines an Error Set Type and any other data type
(e.g. a Primitive Type or a user-defined type such as a struct, enum, or union).
The full form of an error union type is
<error set type>!<any data type>. In the code
sample, the error set type is not explicitly written on the left side of the ! operator.
When written this way, the error set type is an inferred error set type. The
void after the ! operator
tells the compiler that the function will not return a value under normal circumstances (i.e. when no errors occur).
In Zig, a function's block of statements and expressions are surrounded by an open curly-brace { and
close curly-brace }. Inside of the main function are expressions that perform
the task of outputting Hello, world! to standard output.
First, a constant identifier, stdout, is initialized to represent standard output's
writer. Then, the program tries to print the Hello, world!
message to standard output.
Functions sometimes need information to perform their task. In Zig, information is passed
to functions between an open parenthesis ( and a close parenthesis ) placed after
the function's name. This information is also known as arguments. When there are
multiple arguments passed to a function, they are separated by commas ,.
The two arguments passed to the stdout.print() function, "Hello, {s}!\n"
and .{"world"}, are evaluated at compile-time. The code sample is
purposely written to show how to perform string
substitution in the print function. The curly-braces inside of the first argument
are substituted with the compile-time known value inside of the second argument
(known as an anonymous struct literal). The \n
inside of the double-quotes of the first argument is the escape sequence for the
newline character. The try expression evaluates the result of stdout.print.
If the result is an error, then the try expression will return from
main with the error. Otherwise, the program will continue. In this case, there are no
more statements or expressions left to execute in the main function, so the program exits.
In Zig, the standard output writer's print function is allowed to fail because
it is actually a function defined as part of a generic Writer. Consider a generic Writer that
represents writing data to a file. When the disk is full, a write to the file will fail.
However, we typically do not expect writing text to the standard output to fail. To avoid having
to handle the failure case of printing to standard output, you can use alternate functions: the
functions in std.log for proper logging or the std.debug.print function.
This documentation will use the latter option to print to standard error (stderr) and silently return
on failure. The next code sample, hello_again.zig demonstrates the use of
std.debug.print.
const print = @import("std").debug.print;pubfnmain() void {// Comments in Zig start with "//" and end at the next LF byte (end of line).// The line below is a comment and won't be executed.//print("Hello?", .{}); print("Hello, world!\n", .{}); // another comment}
There are no multiline comments in Zig (e.g. like /* */
comments in C). This helps allow Zig to have the property that each line
of code can be tokenized out of context.
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 a/// multiline doc comment).const Timestamp = struct {/// The number of seconds since the epoch (this is also a doc comment). seconds: i64, // signed so we can represent pre-1970 (not a doc comment)/// The number of nanoseconds past the second (doc comment again). nanos: u32,/// Returns a `Timestamp` struct representing the Unix epoch; that is, the/// moment of 1970 Jan 1 00:00:00 UTC (this is a doc comment too).pubfnunixEpoch() Timestamp {return Timestamp{ .seconds = 0, .nanos = 0, }; }};
Doc comments are only allowed in certain places; eventually, it will
become a compile error to have a doc comment in an unexpected place, such as
in the middle of an expression, or just before a non-doc comment.
User documentation that doesn't belong to whatever
immediately follows it, like package-level documentation, goes
in top-level doc comments. A top-level doc comment is one that
begins with two slashes and an exclamation point:
//!.
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.
16-bit floating point (10-bit mantissa) IEEE-754-2008 binary16
f32
float
32-bit floating point (23-bit mantissa) IEEE-754-2008 binary32
f64
double
64-bit floating point (52-bit mantissa) IEEE-754-2008 binary64
f128
_Float128
128-bit floating point (112-bit mantissa) IEEE-754-2008 binary128
bool
bool
true or false
anyopaque
void
Used for type-erased pointers.
void
(none)
0 bit type
noreturn
(none)
the type of break, continue, return, unreachable, and while (true) {}
type
(none)
the type of types
anyerror
(none)
an error code
comptime_int
(none)
Only allowed for comptime-known values. The type of integer literals.
comptime_float
(none)
Only allowed for comptime-known values. The type of float literals.
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.
String literals are constant single-item Pointers to null-terminated byte arrays.
The type of string literals encodes both the length, and the fact that they are null-terminated,
and thus they can be coerced to both Slices and
Null-Terminated Pointers.
Dereferencing string literals converts them to Arrays.
The encoding of a string in Zig is de-facto assumed to be UTF-8.
Because Zig source code is UTF-8 encoded, any non-ASCII bytes appearing within a string literal
in source code carry their UTF-8 meaning into the content of the string in the Zig program;
the bytes are not modified by the compiler.
However, it is possible to embed non-UTF-8 bytes into a string literal using \xNN notation.
Unicode code point literals have type comptime_int, the same as
Integer Literals. All Escape Sequences are valid in both string literals
and Unicode code point literals.
In many other programming languages, a Unicode code point literal is called a "character literal".
However, there is no precise technical definition of a "character"
in recent versions of the Unicode specification (as of Unicode 13.0).
In Zig, a Unicode code point literal corresponds to the Unicode definition of a code point.
string_literals.zig
const print = @import("std").debug.print;const mem = @import("std").mem; // will be used to compare bytespubfnmain() void {const bytes = "hello"; print("{s}\n", .{@typeName(@TypeOf(bytes))}); // *const [5:0]u8 print("{d}\n", .{bytes.len}); // 5 print("{c}\n", .{bytes[1]}); // 'e' print("{d}\n", .{bytes[5]}); // 0 print("{}\n", .{'e' == '\x65'}); // true print("{d}\n", .{'\u{1f4a9}'}); // 128169 print("{d}\n", .{'💯'}); // 128175 print("{}\n", .{mem.eql(u8, "hello", "h\x65llo")}); // true print("0x{x}\n", .{"\xff"[0]}); // non-UTF-8 strings are possible with \xNN notation. print("{u}\n", .{'⚡'});}
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.
Use the const keyword to assign a value to an identifier:
constant_identifier_cannot_change.zig
const x = 1234;fnfoo() void {// It works at file scope as well as inside functions.const y = 5678;// Once assigned, an identifier cannot be changed. y += 1;}pubfnmain() void { foo();}
Shell
$ zig build-exe constant_identifier_cannot_change.zig./docgen_tmp/constant_identifier_cannot_change.zig:8:7: error: cannot assign to constant y += 1;^
const applies to all of the bytes that the identifier immediately addresses. Pointers have their own const-ness.
If you need a variable that you can modify, use the var keyword:
undefined can be coerced to any type.
Once this happens, it is no longer possible to detect that the value is undefined.
undefined means the value could be anything, even something that is nonsense
according to the type. Translated into English, undefined means "Not a meaningful
value. Using this value would be a bug. The value will be unused, or overwritten before being used."
In Debug mode, Zig writes 0xaa bytes to undefined memory. This is to catch
bugs early, and to help detect use of undefined memory in a debugger.
Code written within one or more test declarations can be used to ensure behavior meets expectations:
introducing_zig_test.zig
const std = @import("std");test"expect addOne adds one to 41" {// The Standard Library contains useful functions to help create tests.// `expect` is a function that verifies its argument is true.// It will return an error if its argument is false to indicate a failure.// `try` is used to return an error to the test runner to notify it that the test failed.try std.testing.expect(addOne(41) == 42);}/// The function `addOne` adds one to the number given as its argument.fnaddOne(number: i32) i32 {return number + 1;}
Shell
$ zig test introducing_zig_test.zig1/1 test "expect addOne adds one to 41"... OKAll 1 tests passed.
The introducing_zig_test.zig code sample tests the functionaddOne 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.
The shell output shown above displays two lines after the zig test command. These lines are
printed to standard error by the default test runner:
Test [1/1] test "expect addOne adds one to 41"...
Lines like this indicate which test, out of the total number of tests, is being run.
In this case, [1/1] indicates that the first test, out of a total of
one test, is being run. Note that, when the test runner program's standard error is output
to the terminal, these lines are cleared when a test succeeds.
All 1 tests passed.
This line indicates the total number of tests that have passed.
Test declarations contain the keywordtest, followed by an
optional name written as a string literal, followed
by a block containing any valid Zig code that is allowed in a function.
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 Typeanyerror!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.
When the zig test tool is building a test runner, only resolved test
declarations are included in the build. Initially, only the given Zig source file's top-level
declarations are resolved. Unless nested containers are referenced from a top-level test declaration,
nested container tests will not be resolved.
The code sample below uses the std.testing.refAllDecls(@This()) function call to
reference all of the containers that are in the file including the imported Zig source file. The code
sample also shows an alternative way to reference containers using the _ = C;
syntax. This syntax tells the compiler to ignore the result of the expression on the right side of the
assignment operator.
testdecl_container_top_level.zig
const std = @import("std");const expect = std.testing.expect;// Imported source file tests will run when referenced from a top-level test declaration.// The next line alone does not cause "introducing_zig_test.zig" tests to run.const imported_file = @import("introducing_zig_test.zig");test {// To run nested container tests, either, call `refAllDecls` which will// reference all declarations located in the given argument.// `@This()` is a builtin function that returns the innermost container it is called from.// In this example, the innermost container is this file (implicitly a struct). std.testing.refAllDecls(@This());// or, reference each container individually from a top-level test declaration.// The `_ = C;` syntax is a no-op reference to the identifier `C`. _ = S; _ = U; _ = @import("introducing_zig_test.zig");}const S = struct {test"S demo test" {try expect(true); }const SE = enum { V,// This test won't run because its container (SE) is not referenced.test"This Test Won't Run" {try expect(false); } };};const U = union { // U is referenced by the file's top-level test declaration s: US, // and US is referenced here; therefore, "U.Us demo test" will runconst US = struct {test"U.US demo test" {// This test is a top-level test declaration for the struct.// The struct is nested (declared) inside of a union.try expect(true); } };test"U demo test" {try expect(true); }};
Shell
$ zig test testdecl_container_top_level.zig1/5 test ""... OK2/5 S.test "S demo test"... OK3/5 U.test "U demo test"... OK4/5 introducing_zig_test.test "expect addOne adds one to 41"... OK5/5 US.test "U.US demo test"... OKAll 5 tests passed.
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.
test.zig
const std = @import("std");test"expect this to fail" {try std.testing.expect(false);}test"expect this to succeed" {try std.testing.expect(true);}
Shell
$ zig test test.zig1/2 test "expect this to fail"... test "expect this to fail"... FAIL (TestUnexpectedResult)FAIL (TestUnexpectedResult)/home/andy/tmp/zig/lib/std/testing.zig:303:14: 0x207ebb in std.testing.expect (test) if (!ok) return error.TestUnexpectedResult;^/home/andy/tmp/zig/docgen_tmp/test.zig:4:5: 0x2078f1 in test "expect this to fail" (test) try std.testing.expect(false);^2/2 test "expect this to succeed"... OK1 passed; 0 skipped; 1 failed.error: the following test command failed with exit code 1:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
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.
test.zig
test"this will be skipped" {returnerror.SkipZigTest;}
Shell
$ zig test test.zig1/1 test "this will be skipped"... test "this will be skipped"... SKIPSKIP0 passed; 1 skipped; 0 failed.
The default test runner skips tests containing a suspend point while the
test is running using the default, blocking IO mode.
(The evented IO mode is enabled using the --test-evented-io command line parameter.)
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:
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_functions.zig
const std = @import("std");test"expectEqual demo" {const expected: i32 = 42;const actual = 42;// The first argument to `expectEqual` is the known, expected, result.// The second argument is the result of some expression.// The actual's type is casted to the type of expected.try std.testing.expectEqual(expected, actual);}test"expectError demo" {const expected_error = error.DemoError;const actual_error_union: anyerror!void = error.DemoError;// `expectError` will fail when the actual error is different than// the expected error.try std.testing.expectError(expected_error, actual_error_union);}
Shell
$ zig test testing_functions.zig1/2 test "expectEqual demo"... OK2/2 test "expectError demo"... OKAll 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.
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.
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.
test.zig
const @"identifier with spaces in it" = 0xff;const @"1SmallStep4Man" = 112358;const c = @import("std").c;pubextern"c"fn@"error"() anyopaque;pubextern"c"fn@"fstat$INODE64"(fd: c.fd_t, buf: *c.Stat) c_int;const Color = enum { red, @"really red",};const color: Color = .@"really red";
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.
$ zig test static_local_variable.zig1/1 test "static local variable"... OKAll 1 tests passed.
The extern keyword or @extern builtin function can be used to link against a variable that is exported
from another object. The export keyword or @export builtin function
can be used to make a variable available to other objects at link time. In both cases,
the type of the variable must be C ABI compatible.
When a local variable is const, it means that after initialization, the variable's
value will not change. If the initialization value of a const variable is
comptime-known, then the variable is also comptime-known.
A local variable may be qualified with the comptime keyword. This causes
the variable's value to be comptime-known, and all loads and stores of the
variable to happen during semantic analysis of the program, rather than at runtime.
All variables declared in a comptime expression are implicitly
comptime variables.
comptime_vars.zig
const std = @import("std");const expect = std.testing.expect;test"comptime vars" {var x: i32 = 1;comptimevar y: i32 = 1; x += 1; y += 1;try expect(x == 2);try expect(y == 2);if (y != 2) {// This compile error never triggers because y is a comptime variable,// and so `y != 2` is a comptime value, and this if is statically evaluated.@compileError("wrong y value"); }}
Shell
$ zig test comptime_vars.zig1/1 test "comptime vars"... OKAll 1 tests passed.
Integer literals have no size limitation, and if any undefined behavior occurs,
the compiler catches it.
However, once an integer value is no longer known at compile-time, it must have a
known size, and is vulnerable to undefined behavior.
runtime_vs_comptime.zig
fndivide(a: i32, b: i32) i32 {return a / b;}
In this function, values a and b are known only at runtime,
and thus this division operation is vulnerable to both Integer Overflow and
Division by Zero.
Operators such as + and - cause undefined behavior on
integer overflow. Alternative operators are provided for wrapping and saturating arithmetic on all targets.
+% and -% perform wrapping arithmetic
while +| and -| perform saturating arithmetic.
Zig supports arbitrary bit-width integers, referenced by using
an identifier of i or u followed by digits. For example, the identifier
i7 refers to a signed 7-bit integer. The maximum allowed bit-width of an
integer type is 65535.
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;const hex_floating_point = 0x103.70p-5;const another_hex_float = 0x103.70;const yet_another_hex_float = 0x103.70P-5;// underscores may be placed between two digits as a visual separatorconst lightspeed = 299_792_458.000_000;const nanosecond = 0.000_000_001;const more_hex = 0x1234_5678.9ABC_CDEFp-10;
There is no syntax for NaN, infinity, or negative infinity. For these special values,
one must use the standard library:
By default floating point operations use Strict mode,
but you can switch to Optimized mode on a per-block basis:
foo.zig
const std = @import("std");const big = @as(f64, 1 << 40);exportfnfoo_strict(x: f64) f64 {return x + big - big;}exportfnfoo_optimized(x: f64) f64 {@setFloatMode(.Optimized);return x + big - big;}
Shell
$ zig build-obj foo.zig -O ReleaseFast
For this test we have to separate code into two object files -
otherwise the optimizer figures out all the values at compile-time,
which operates in strict mode.
If a is an error,
returns b ("default value"),
otherwise returns the unwrapped value of a.
Note that b may be a value of type noreturn.
err is the error and is in scope of the expression b.
const expect = @import("std").testing.expect;const assert = @import("std").debug.assert;const mem = @import("std").mem;// array literalconst message = [_]u8{ 'h', 'e', 'l', 'l', 'o' };// get the size of an arraycomptime { assert(message.len == 5);}// A string literal is a single-item pointer to an array literal.const same_message = "hello";comptime { assert(mem.eql(u8, &message, same_message));}test"iterate over an array" {var sum: usize = 0;for (message) |byte| { sum += byte; }try expect(sum == 'h' + 'e' + 'l' * 2 + 'o');}// modifiable arrayvar some_integers: [100]i32 = undefined;test"modify an array" {for (some_integers) |*item, i| { item.* = @intCast(i32, i); }try expect(some_integers[10] == 10);try expect(some_integers[99] == 99);}// array concatenation works if the values are known// at compile timeconst part_one = [_]i32{ 1, 2, 3, 4 };const part_two = [_]i32{ 5, 6, 7, 8 };const all_of_it = part_one ++ part_two;comptime { assert(mem.eql(i32, &all_of_it, &[_]i32{ 1, 2, 3, 4, 5, 6, 7, 8 }));}// remember that string literals are arraysconst hello = "hello";const world = "world";const hello_world = hello ++ " " ++ world;comptime { assert(mem.eql(u8, hello_world, "hello world"));}// ** does repeating patternsconst pattern = "ab" ** 3;comptime { assert(mem.eql(u8, pattern, "ababab"));}// initialize an array to zeroconst all_zero = [_]u16{0} ** 10;comptime { assert(all_zero.len == 10); assert(all_zero[5] == 0);}// use compile-time code to initialize an arrayvar fancy_array = init: {var initial_value: [10]Point = undefined;for (initial_value) |*pt, i| { pt.* = Point{ .x = @intCast(i32, i), .y = @intCast(i32, i) * 2, }; }break :init initial_value;};const Point = struct { x: i32, y: i32,};test"compile-time array initialization" {try expect(fancy_array[4].x == 4);try expect(fancy_array[4].y == 8);}// call a function to initialize an arrayvar more_points = [_]Point{makePoint(3)} ** 10;fnmakePoint(x: i32) Point {return Point{ .x = x, .y = x * 2, };}test"array initialization with function calls" {try expect(more_points[4].x == 3);try expect(more_points[4].y == 6);try expect(more_points.len == 10);}
Shell
$ zig test arrays.zig1/4 test "iterate over an array"... OK2/4 test "modify an array"... OK3/4 test "compile-time array initialization"... OK4/4 test "array initialization with function calls"... OKAll 4 tests passed.
A vector is a group of booleans, Integers, Floats, or Pointers which are operated on
in parallel using SIMD instructions. Vector types are created with the builtin function @Type,
or using the shorthand function std.meta.Vector.
Vectors support the same builtin operators as their underlying base types. These operations are performed
element-wise, and return a vector of the same length as the input vectors. This includes:
It is prohibited to use a math operator on a mixture of scalars (individual numbers) and vectors.
Zig provides the @splat builtin to easily convert from scalars to vectors, and it supports @reduce
and array indexing syntax to convert from vectors to scalars. Vectors also support assignment to and from
fixed-length arrays with comptime known length.
For rearranging elements within and between vectors, Zig provides the @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.
vector_example.zig
const std = @import("std");const Vector = std.meta.Vector;const expectEqual = std.testing.expectEqual;test"Basic vector usage" {// Vectors have a compile-time known length and base type,// and can be assigned to using array literal syntaxconst a: Vector(4, i32) = [_]i32{ 1, 2, 3, 4 };const b: Vector(4, i32) = [_]i32{ 5, 6, 7, 8 };// Math operations take place element-wiseconst c = a + b;// Individual vector elements can be accessed using array indexing syntax.try expectEqual(6, c[0]);try expectEqual(8, c[1]);try expectEqual(10, c[2]);try expectEqual(12, c[3]);}test"Conversion between vectors, arrays, and slices" {// Vectors and fixed-length arrays can be automatically assigned back and forthvar arr1: [4]f32 = [_]f32{ 1.1, 3.2, 4.5, 5.6 };var vec: Vector(4, f32) = arr1;var arr2: [4]f32 = vec;try expectEqual(arr1, arr2);// You can also assign from a slice with comptime-known length to a vector using .*const vec2: Vector(2, f32) = arr1[1..3].*;var slice: []constf32 = &arr1;var offset: u32 = 1;// To extract a comptime-known length from a runtime-known offset,// first extract a new slice from the starting offset, then an array of// comptime known lengthconst vec3: Vector(2, f32) = slice[offset..][0..2].*;try expectEqual(slice[offset], vec2[0]);try expectEqual(slice[offset + 1], vec2[1]);try expectEqual(vec2, vec3);}
Shell
$ zig test vector_example.zig1/2 test "Basic vector usage"... OK2/2 test "Conversion between vectors, arrays, and slices"... OKAll 2 tests passed.
TODO talk about C ABI interop
TODO consider suggesting std.MultiArrayList
Zig has two kinds of pointers: single-item and many-item.
*T - single-item pointer to exactly one item.
Supports deref syntax: ptr.*
[*]T - many-item pointer to unknown number of items.
Supports index syntax: ptr[i]
Supports slice syntax: ptr[start..end]
Supports pointer arithmetic: ptr + x, ptr - x
T must have a known size, which means that it cannot be
anyopaque or any other opaque type.
These types are closely related to Arrays and Slices:
*[N]T - pointer to N items, same as single-item pointer to an array.
Supports index syntax: array_ptr[i]
Supports slice syntax: array_ptr[start..end]
Supports len property: array_ptr.len
[]T - pointer to runtime-known number of items.
Supports index syntax: slice[i]
Supports slice syntax: slice[start..end]
Supports len property: slice.len
Use &x to obtain a single-item pointer:
single_item_pointer_test.zig
const expect = @import("std").testing.expect;test"address of syntax" {// Get the address of a variable:const x: i32 = 1234;const x_ptr = &x;// Dereference a pointer:try expect(x_ptr.* == 1234);// When you get the address of a const variable, you get a const single-item pointer.try expect(@TypeOf(x_ptr) == *consti32);// If you want to mutate the value, you'd need an address of a mutable variable:var y: i32 = 5678;const y_ptr = &y;try expect(@TypeOf(y_ptr) == *i32); y_ptr.* += 1;try expect(y_ptr.* == 5679);}test"pointer array access" {// Taking an address of an individual element gives a// single-item pointer. This kind of pointer// does not support pointer arithmetic.var array = [_]u8{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };const ptr = &array[2];try expect(@TypeOf(ptr) == *u8);try expect(array[2] == 3); ptr.* += 1;try expect(array[2] == 4);}
Shell
$ zig test single_item_pointer_test.zig1/2 test "address of syntax"... OK2/2 test "pointer array access"... OKAll 2 tests passed.
In Zig, we generally prefer Slices rather than Sentinel-Terminated Pointers.
You can turn an array or pointer into a slice using slice syntax.
Slices have bounds checking and are therefore protected
against this kind of undefined behavior. This is one reason
we prefer slices to pointers.
$ zig test integer_pointer_conversion.zig1/1 test "@ptrToInt and @intToPtr"... OKAll 1 tests passed.
Zig is able to preserve memory addresses in comptime code, as long as
the pointer is never dereferenced:
comptime_pointer_conversion.zig
const expect = @import("std").testing.expect;test"comptime @intToPtr" {comptime {// Zig is able to do this at compile-time, as long as// ptr is never dereferenced.const ptr = @intToPtr(*i32, 0xdeadbee0);const addr = @ptrToInt(ptr);try expect(@TypeOf(addr) == usize);try expect(addr == 0xdeadbee0); }}
Shell
$ zig test comptime_pointer_conversion.zig1/1 test "comptime @intToPtr"... OKAll 1 tests passed.
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:
$ zig test volatile.zig1/1 test "volatile"... OKAll 1 tests passed.
Note that volatile is unrelated to concurrency and Atomics.
If you see code that is using volatile for something other than Memory Mapped
Input/Output, it is probably a bug.
To convert one pointer type to another, use @ptrCast. This is an unsafe
operation that Zig cannot protect you against. Use @ptrCast only when other
conversions are not possible.
pointer_casting.zig
const std = @import("std");const expect = std.testing.expect;test"pointer casting" {const bytes align(@alignOf(u32)) = [_]u8{ 0x12, 0x12, 0x12, 0x12 };const u32_ptr = @ptrCast(*constu32, &bytes);try expect(u32_ptr.* == 0x12121212);// Even this example is contrived - there are better ways to do the above than// pointer casting. For example, using a slice narrowing cast:const u32_value = std.mem.bytesAsSlice(u32, bytes[0..])[0];try expect(u32_value == 0x12121212);// And even another way, the most straightforward way to do it:try expect(@bitCast(u32, bytes) == 0x12121212);}test"pointer child type" {// pointer types have a `child` field which tells you the type they point to.try expect(@typeInfo(*u32).Pointer.child == u32);}
Shell
$ zig test pointer_casting.zig1/2 test "pointer casting"... OK2/2 test "pointer child type"... OKAll 2 tests passed.
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:
$ zig test variable_alignment.zig1/1 test "variable alignment"... OKAll 1 tests passed.
In the same way that a *i32 can be coerced to a
*consti32, 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:
$ zig test variable_func_alignment.zig1/2 test "global variable alignment"... OK2/2 test "function alignment"... OKAll 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:
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:
The syntax [*:x]T describes a pointer that
has a length determined by a sentinel value. This provides protection
against buffer overflow and overreads.
test.zig
const std = @import("std");// This is also available as `std.c.printf`.pubextern"c"fnprintf(format: [*:0]constu8, ...) c_int;pubfnmain() anyerror!void { _ = printf("Hello, world!\n"); // OKconst msg = "Hello, world!\n";const non_null_terminated_msg: [msg.len]u8 = msg.*; _ = printf(&non_null_terminated_msg);}
Shell
$ zig build-exe test.zig -lc./docgen_tmp/test.zig:11:17: error: expected type '[*:0]const u8', found '*const [14]u8' _ = printf(&non_null_terminated_msg);^./docgen_tmp/test.zig:11:17: note: destination pointer requires a terminating '0' sentinel _ = printf(&non_null_terminated_msg);^
const expect = @import("std").testing.expect;test"basic slices" {var array = [_]i32{ 1, 2, 3, 4 };// A slice is a pointer and a length. The difference between an array and// a slice is that the array's length is part of the type and known at// compile-time, whereas the slice's length is known at runtime.// Both can be accessed with the `len` field.var known_at_runtime_zero: usize = 0;const slice = array[known_at_runtime_zero..array.len];try expect(&slice[0] == &array[0]);try expect(slice.len == array.len);// Using the address-of operator on a slice gives a single-item pointer,// while using the `ptr` field gives a many-item pointer.try expect(@TypeOf(slice.ptr) == [*]i32);try expect(@TypeOf(&slice[0]) == *i32);try expect(@ptrToInt(slice.ptr) == @ptrToInt(&slice[0]));// Slices have array bounds checking. If you try to access something out// of bounds, you'll get a safety check failure: slice[10] += 1;// Note that `slice.ptr` does not invoke safety checking, while `&slice[0]`// asserts that the slice has len >= 1.}
Shell
$ zig test test.zig1/1 test "basic slices"... thread 1425797 panic: index out of bounds/home/andy/tmp/zig/docgen_tmp/test.zig:22:10: 0x207b23 in test "basic slices" (test) slice[10] += 1;^/home/andy/tmp/zig/lib/std/special/test_runner.zig:80:28: 0x22f3d3 in std.special.main (test) } else test_fn.func();^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x22874c in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x2093de in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x208476 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x208282 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^error: the following test command crashed:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
This is one reason we prefer slices to pointers.
slices.zig
const std = @import("std");const expect = std.testing.expect;const mem = std.mem;const fmt = std.fmt;test"using slices for strings" {// Zig has no concept of strings. String literals are const pointers// to null-terminated arrays of u8, and by convention parameters// that are "strings" are expected to be UTF-8 encoded slices of u8.// Here we coerce *const [5:0]u8 and *const [6:0]u8 to []const u8const hello: []constu8 = "hello";const world: []constu8 = "世界";var all_together: [100]u8 = undefined;// You can use slice syntax on an array to convert an array into a slice.const all_together_slice = all_together[0..];// String concatenation example.const hello_world = try fmt.bufPrint(all_together_slice, "{s} {s}", .{ hello, world });// Generally, you can use UTF-8 and not worry about whether something is a// string. If you don't need to deal with individual characters, no need// to decode.try expect(mem.eql(u8, hello_world, "hello 世界"));}test"slice pointer" {var array: [10]u8 = undefined;const ptr = &array;// You can use slicing syntax to convert a pointer into a slice:const slice = ptr[0..5]; slice[2] = 3;try expect(slice[2] == 3);// The slice is mutable because we sliced a mutable pointer.// Furthermore, it is actually a pointer to an array, since the start// and end indexes were both comptime-known.try expect(@TypeOf(slice) == *[5]u8);// You can also slice a slice:const slice2 = slice[2..3];try expect(slice2.len == 1);try expect(slice2[0] == 3);}
Shell
$ zig test slices.zig1/2 test "using slices for strings"... OK2/2 test "slice pointer"... OKAll 2 tests passed.
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.
$ zig test null_terminated_slice.zig1/1 test "null terminated slice"... OKAll 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.
$ zig test null_terminated_slicing.zig1/1 test "null terminated slicing"... OKAll 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-protected Undefined Behavior results.
test.zig
const std = @import("std");const expect = std.testing.expect;test"sentinel mismatch" {var array = [_]u8{ 3, 2, 1, 0 };// Creating a sentinel-terminated slice from the array with a length of 2// will result in the value `1` occupying the sentinel element position.// This does not match the indicated sentinel value of `0` and will lead// to a runtime panic.var runtime_length: usize = 2;const slice = array[0..runtime_length :0]; _ = slice;}
Shell
$ zig test test.zig1/1 test "sentinel mismatch"... thread 1426374 panic: sentinel mismatch/home/andy/tmp/zig/docgen_tmp/test.zig:12:24: 0x2078ca in test "sentinel mismatch" (test) const slice = array[0..runtime_length :0];^/home/andy/tmp/zig/lib/std/special/test_runner.zig:80:28: 0x22f153 in std.special.main (test) } else test_fn.func();^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x2284cc in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x20910e in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x2081a6 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x207fb2 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^error: the following test command crashed:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
// Declare a struct.// Zig gives no guarantees about the order of fields and the size of// the struct but the fields are guaranteed to be ABI-aligned.const Point = struct { x: f32, y: f32,};// Maybe we want to pass it to OpenGL so we want to be particular about// how the bytes are arranged.const Point2 = packedstruct { x: f32, y: f32,};// Declare an instance of a struct.const p = Point { .x = 0.12, .y = 0.34,};// Maybe we're not ready to fill out some of the fields.var p2 = Point { .x = 0.12, .y = undefined,};// Structs can have methods// Struct methods are not special, they are only namespaced// functions that you can call with dot syntax.const Vec3 = struct { x: f32, y: f32, z: f32,pubfninit(x: f32, y: f32, z: f32) Vec3 {return Vec3 { .x = x, .y = y, .z = z, }; }pubfndot(self: Vec3, other: Vec3) f32 {return self.x * other.x + self.y * other.y + self.z * other.z; }};const expect = @import("std").testing.expect;test"dot product" {const v1 = Vec3.init(1.0, 0.0, 0.0);const v2 = Vec3.init(0.0, 1.0, 0.0);try expect(v1.dot(v2) == 0.0);// Other than being available to call with dot syntax, struct methods are// not special. You can reference them as any other declaration inside// the struct:try expect(Vec3.dot(v1, v2) == 0.0);}// Structs can have declarations.// Structs can have 0 fields.const Empty = struct {pubconst PI = 3.14;};test"struct namespaced variable" {try expect(Empty.PI == 3.14);try expect(@sizeOf(Empty) == 0);// you can still instantiate an empty structconst does_nothing = Empty {}; _ = does_nothing;}// struct field order is determined by the compiler for optimal performance.// however, you can still calculate a struct base pointer given a field pointer:fnsetYBasedOnX(x: *f32, y: f32) void {const point = @fieldParentPtr(Point, "x", x); point.y = y;}test"field parent pointer" {var point = Point { .x = 0.1234, .y = 0.5678, }; setYBasedOnX(&point.x, 0.9);try expect(point.y == 0.9);}// You can return a struct from a function. This is how we do generics// in Zig:fnLinkedList(comptime T: type) type {returnstruct {pubconst Node = struct { prev: ?*Node, next: ?*Node, data: T, }; first: ?*Node, last: ?*Node, len: usize, };}test"linked list" {// Functions called at compile-time are memoized. This means you can// do this:try expect(LinkedList(i32) == LinkedList(i32));var list = LinkedList(i32) { .first = null, .last = null, .len = 0, };try expect(list.len == 0);// Since types are first class values you can instantiate the type// by assigning it to a variable:const ListOfInts = LinkedList(i32);try expect(ListOfInts == LinkedList(i32));var node = ListOfInts.Node { .prev = null, .next = null, .data = 1234, };var list2 = LinkedList(i32) { .first = &node, .last = &node, .len = 1, };// When using a pointer to a struct, fields can be accessed directly,// without explicitly dereferencing the pointer.// So you can dotry expect(list2.first.?.data == 1234);// instead of try expect(list2.first.?.*.data == 1234);}
Shell
$ zig test structs.zig1/4 test "dot product"... OK2/4 test "struct namespaced variable"... OK3/4 test "field parent pointer"... OK4/4 test "linked list"... OKAll 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:
Unlike normal structs, packed structs have guaranteed in-memory layout:
Fields remain in the order declared.
There is no padding between fields.
Zig supports arbitrary width Integers and although normally, integers with fewer
than 8 bits will still use 1 byte of memory, in packed structs, they use
exactly their bit width.
bool fields use exactly 1 bit.
An enum field uses exactly the bit width of its integer tag type.
A packed union field uses exactly the bit width of the union field with
the largest bit width.
Non-ABI-aligned fields are packed into the smallest possible
ABI-aligned integers in accordance with the target endianness.
This means that a packedstruct can participate
in a @bitCast or a @ptrCast to reinterpret memory.
This even works at comptime:
$ zig test test.zig./docgen_tmp/test.zig:17:30: error: expected type '*const u3', found '*align(:3:1) u3' try expect(bar(&bit_field.b) == 2);^
In this case, the function bar cannot be called 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:
$ zig test test_bitOffsetOf_offsetOf.zig1/1 test "pointer to non-bit-aligned field"... OKAll 1 tests passed.
Packed structs have 1-byte alignment. However if you have an overaligned pointer to a packed struct,
Zig should correctly understand the alignment of fields. However there is
a bug:
test.zig
const S = packedstruct { a: u32, b: u32,};test"overaligned pointer to packed struct" {var foo: S align(4) = undefined;const ptr: *align(4) S = &foo;const ptr_to_b: *u32 = &ptr.b; _ = ptr_to_b;}
Shell
$ zig test test.zig./docgen_tmp/test.zig:8:32: error: expected type '*u32', found '*align(1) u32' const ptr_to_b: *u32 = &ptr.b;^
When this bug is fixed, the above test in the documentation will unexpectedly pass, which will
cause the test suite to fail, notifying the bug fixer to update these docs.
It's also possible to set alignment of struct fields:
$ zig test test_aligned_struct_fields.zig1/1 test "aligned struct fields"... OKAll 1 tests passed.
Using packed structs with volatile is problematic, and may be a compile error in the future.
For details on this subscribe to
this issue.
TODO update these docs with a recommendation on how to use packed structs with MMIO
(the use case for volatile packed structs) once this issue is resolved.
Don't worry, there will be a good solution for this use case in zig.
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:
$ zig test struct_anon.zig1/1 test "fully anonymous struct"... OKAll 1 tests passed.
Anonymous structs can be created without specifying field names, and are referred to as "tuples".
The fields are implicitly named using numbers starting from 0. Because their names are integers,
the @"0" syntax must be used to access them. Names inside @"" are always recognised as identifiers.
Like arrays, tuples have a .len field, can be indexed and work with the ++ and ** operators. They can also be iterated over with inline for.
const expect = @import("std").testing.expect;const mem = @import("std").mem;// Declare an enum.const Type = enum { ok, not_ok,};// Declare a specific instance of the enum variant.const c = Type.ok;// If you want access to the ordinal value of an enum, you// can specify the tag type.const Value = enum(u2) { zero, one, two,};// Now you can cast between u2 and Value.// The ordinal value starts from 0, counting up for each member.test"enum ordinal value" {try expect(@enumToInt(Value.zero) == 0);try expect(@enumToInt(Value.one) == 1);try expect(@enumToInt(Value.two) == 2);}// You can override the ordinal value for an enum.const Value2 = enum(u32) { hundred = 100, thousand = 1000, million = 1000000,};test"set enum ordinal value" {try expect(@enumToInt(Value2.hundred) == 100);try expect(@enumToInt(Value2.thousand) == 1000);try expect(@enumToInt(Value2.million) == 1000000);}// Enums can have methods, the same as structs and unions.// Enum methods are not special, they are only namespaced// functions that you can call with dot syntax.const Suit = enum { clubs, spades, diamonds, hearts,pubfnisClubs(self: Suit) bool {return self == Suit.clubs; }};test"enum method" {const p = Suit.spades;try expect(!p.isClubs());}// An enum variant of different types can be switched upon.const Foo = enum { string, number, none,};test"enum variant switch" {const p = Foo.number;const what_is_it = switch (p) { Foo.string => "this is a string", Foo.number => "this is a number", Foo.none => "this is a none", };try expect(mem.eql(u8, what_is_it, "this is a number"));}// @typeInfo can be used to access the integer tag type of an enum.const Small = enum { one, two, three, four,};test"std.meta.Tag" {try expect(@typeInfo(Small).Enum.tag_type == u2);}// @typeInfo tells us the field count and the fields names:test"@typeInfo" {try expect(@typeInfo(Small).Enum.fields.len == 4);try expect(mem.eql(u8, @typeInfo(Small).Enum.fields[1].name, "two"));}// @tagName gives a [:0]const u8 representation of an enum value:test"@tagName" {try expect(mem.eql(u8, @tagName(Small.three), "three"));}
Shell
$ zig test enums.zig1/7 test "enum ordinal value"... OK2/7 test "set enum ordinal value"... OK3/7 test "enum method"... OK4/7 test "enum variant switch"... OK5/7 test "std.meta.Tag"... OK6/7 test "@typeInfo"... OK7/7 test "@tagName"... OKAll 7 tests passed.
By default, enums are not guaranteed to be compatible with the C ABI:
test.zig
const Foo = enum { a, b, c };exportfnentry(foo: Foo) void { _ = foo; }
Shell
$ zig build-obj test.zig./docgen_tmp/test.zig:2:22: error: parameter of type 'Foo' not allowed in function with calling convention 'C'export fn entry(foo: Foo) void { _ = foo; }^
For a C-ABI-compatible enum, provide an explicit tag type to
the enum:
test.zig
const Foo = enum(c_int) { a, b, c };exportfnentry(foo: Foo) void { _ = foo; }
A Non-exhaustive enum can be created by adding a trailing '_' field.
It must specify a tag type and cannot consume every enumeration value.
@intToEnum on a non-exhaustive enum 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 the difference being that it makes it a compile error if all the known tag names are not handled by the switch.
A bare union defines a set of possible types that a value
can be as a list of fields. Only one field can be active at a time.
The in-memory representation of bare unions is not guaranteed.
Bare unions cannot be used to reinterpret memory. For that, use @ptrCast,
or use an extern union or a packed union which have
guaranteed in-memory layout.
Accessing the non-active field is
safety-checked Undefined Behavior:
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.
$ zig test test_switch_tagged_union.zig1/3 test "switch on tagged union"... OK2/3 test "get tag type"... OK3/3 test "coerce to enum"... OKAll 3 tests passed.
In order to modify the payload of a tagged union in a switch expression,
place a * before the variable name to make it a pointer:
$ zig test test.zig./docgen_tmp/test.zig:6:9: error: expected type '*Derp', found '*Wat' bar(w);^./docgen_tmp/test.zig:6:9: note: pointer type child 'Wat' cannot cast into pointer type child 'Derp' bar(w);^
Identifiers are never allowed to "hide" other identifiers by using the same name:
test.zig
const pi = 3.14;test"inside test block" {// Let's even go inside another block {var pi: i32 = 1234; }}
Shell
$ zig test test.zigdocgen_tmp/test.zig:6:13: error: local shadows declaration of 'pi'
var pi: i32 = 1234;^docgen_tmp/test.zig:1:1: note: declared here
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:
const std = @import("std");const builtin = @import("builtin");const expect = std.testing.expect;test"switch simple" {const a: u64 = 10;const zz: u64 = 103;// All branches of a switch expression must be able to be coerced to a// common type.//// Branches cannot fallthrough. If fallthrough behavior is desired, combine// the cases and use an if.const b = switch (a) {// Multiple cases can be combined via a ','1, 2, 3 => 0,// Ranges can be specified using the ... syntax. These are inclusive// of both ends.5...100 => 1,// Branches can be arbitrarily complex.101 => blk: {const c: u64 = 5;break :blk c * 2 + 1; },// Switching on arbitrary expressions is allowed as long as the// expression is known at compile-time. zz => zz, blk: {const d: u32 = 5;const e: u32 = 100;break :blk d + e; } => 107,// The else branch catches everything not already captured.// Else branches are mandatory unless the entire range of values// is handled.else => 9, };try expect(b == 1);}// Switch expressions can be used outside a function:const os_msg = switch (builtin.target.os.tag) { .linux => "we found a linux user",else => "not a linux user",};// Inside a function, switch statements implicitly are compile-time// evaluated if the target expression is compile-time known.test"switch inside function" {switch (builtin.target.os.tag) { .fuchsia => {// On an OS other than fuchsia, block is not even analyzed,// so this compile error is not triggered.// On fuchsia this compile error would be triggered.@compileError("fuchsia not supported"); },else => {}, }}
Shell
$ zig test switch.zig1/2 test "switch simple"... OK2/2 test "switch inside function"... OKAll 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;test"switch on tagged union" {const Point = struct { x: u8, y: u8, };const Item = union(enum) { a: u32, c: Point, d, e: u32, };var a = Item{ .c = Point{ .x = 1, .y = 2 } };// Switching on more complex enums is allowed.const b = switch (a) {// A capture group is allowed on a match, and will return the enum// value matched. If the payload types of both cases are the same// they can be put into the same switch prong. Item.a, Item.e => |item| item,// A reference to the matched value can be obtained using `*` syntax. Item.c => |*item| blk: { item.*.x += 1;break :blk 6; },// No else is required if the types cases was exhaustively handled Item.d => 8, };try expect(b == 6);try expect(a.c.x == 2);}
Shell
$ zig test test_switch_tagged_union.zig1/1 test "switch on tagged union"... OKAll 1 tests passed.
$ zig test while.zig1/2 test "while loop continue expression"... OK2/2 test "while loop continue expression, more complicated"... OKAll 2 tests passed.
While loops are expressions. The result of the expression is the
result of the else clause of a while loop, which is executed when
the condition of the while loop is tested as false.
break, like return, accepts a value
parameter. This is the result of the while expression.
When you break from a while loop, the else branch is not
evaluated.
while.zig
const expect = @import("std").testing.expect;test"while else" {try expect(rangeHasNumber(0, 10, 5));try expect(!rangeHasNumber(0, 10, 15));}fnrangeHasNumber(begin: usize, end: usize, number: usize) bool {var i = begin;returnwhile (i < end) : (i += 1) {if (i == number) {breaktrue; } } elsefalse;}
Shell
$ zig test while.zig1/1 test "while else"... OKAll 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.
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;test"inline while loop" {comptimevar i = 0;var sum: usize = 0;inlinewhile (i < 3) : (i += 1) {const T = switch (i) {0 => f32,1 => i8,2 => bool,else => unreachable, }; sum += typeNameLength(T); }try expect(sum == 9);}fntypeNameLength(comptime T: type) usize {return@typeName(T).len;}
Shell
$ zig test test_inline_while.zig1/1 test "inline while loop"... OKAll 1 tests passed.
It is recommended to use inline loops only for one of these reasons:
You need the loop to execute at comptime for the semantics to work.
You have a benchmark to prove that forcibly unrolling the loop in this way is measurably faster.
const expect = @import("std").testing.expect;test"for basics" {const items = [_]i32 { 4, 5, 3, 4, 0 };var sum: i32 = 0;// For loops iterate over slices and arrays.for (items) |value| {// Break and continue are supported.if (value == 0) {continue; } sum += value; }try expect(sum == 16);// To iterate over a portion of a slice, reslice.for (items[0..1]) |value| { sum += value; }try expect(sum == 20);// To access the index of iteration, specify a second capture value.// This is zero-indexed.var sum2: i32 = 0;for (items) |_, i| {try expect(@TypeOf(i) == usize); sum2 += @intCast(i32, i); }try expect(sum2 == 10);}test"for reference" {var items = [_]i32 { 3, 4, 2 };// Iterate over the slice by reference by// specifying that the capture value is a pointer.for (items) |*value| { value.* += 1; }try expect(items[0] == 4);try expect(items[1] == 5);try expect(items[2] == 3);}test"for else" {// For allows an else attached to it, the same as a while loop.var items = [_]?i32 { 3, 4, null, 5 };// For loops can also be used as expressions.// Similar to while loops, when you break from a for loop, the else branch is not evaluated.var sum: i32 = 0;const result = for (items) |value| {if (value != null) { sum += value.?; } } else blk: {try expect(sum == 12);break :blk sum; };try expect(result == 12);}
Shell
$ zig test for.zig1/3 test "for basics"... OK2/3 test "for reference"... OK3/3 test "for else"... OKAll 3 tests passed.
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.
// If expressions have three uses, corresponding to the three types:// * bool// * ?T// * anyerror!Tconst expect = @import("std").testing.expect;test"if expression" {// If expressions are used instead of a ternary expression.const a: u32 = 5;const b: u32 = 4;const result = if (a != b) 47else3089;try expect(result == 47);}test"if boolean" {// If expressions test boolean conditions.const a: u32 = 5;const b: u32 = 4;if (a != b) {try expect(true); } elseif (a == 9) {unreachable; } else {unreachable; }}test"if optional" {// If expressions test for null.const a: ?u32 = 0;if (a) |value| {try expect(value == 0); } else {unreachable; }const b: ?u32 = null;if (b) |_| {unreachable; } else {try expect(true); }// The else is not required.if (a) |value| {try expect(value == 0); }// To test against null only, use the binary equality operator.if (b == null) {try expect(true); }// Access the value by reference using a pointer capture.var c: ?u32 = 3;if (c) |*value| { value.* = 2; }if (c) |value| {try expect(value == 2); } else {unreachable; }}test"if error union" {// If expressions test for errors.// Note the |err| capture on the else.const a: anyerror!u32 = 0;if (a) |value| {try expect(value == 0); } else |err| { _ = err;unreachable; }const b: anyerror!u32 = error.BadValue;if (b) |value| { _ = value;unreachable; } else |err| {try expect(err == error.BadValue); }// The else and |err| capture is strictly required.if (a) |value| {try expect(value == 0); } else |_| {}// To check only the error value, use an empty block expression.if (b) |_| {} else |err| {try expect(err == error.BadValue); }// Access the value by reference using a pointer capture.var c: anyerror!u32 = 3;if (c) |*value| { value.* = 9; } else |_| {unreachable; }if (c) |value| {try expect(value == 9); } else |_| {unreachable; }}test"if error union with optional" {// If expressions test for errors before unwrapping optionals.// The |optional_value| capture's type is ?u32.const a: anyerror!?u32 = 0;if (a) |optional_value| {try expect(optional_value.? == 0); } else |err| { _ = err;unreachable; }const b: anyerror!?u32 = null;if (b) |optional_value| {try expect(optional_value == null); } else |_| {unreachable; }const c: anyerror!?u32 = error.BadValue;if (c) |optional_value| { _ = optional_value;unreachable; } else |err| {try expect(err == error.BadValue); }// Access the value by reference by using a pointer capture each time.var d: anyerror!?u32 = 3;if (d) |*optional_value| {if (optional_value.*) |*value| { value.* = 9; } } else |_| {unreachable; }if (d) |optional_value| {try expect(optional_value.? == 9); } else |_| {unreachable; }}
Shell
$ zig test if.zig1/5 test "if expression"... OK2/5 test "if boolean"... OK3/5 test "if optional"... OK4/5 test "if error union"... OK5/5 test "if error union with optional"... OKAll 5 tests passed.
const std = @import("std");const expect = std.testing.expect;const print = std.debug.print;// defer will execute an expression at the end of the current scope.fndeferExample() !usize {var a: usize = 1; {defer a = 2; a = 1; }try expect(a == 2); a = 5;return a;}test"defer basics" {try expect((try deferExample()) == 5);}// If multiple defer statements are specified, they will be executed in// the reverse order they were run.fndeferUnwindExample() void { print("\n", .{});defer { print("1 ", .{}); }defer { print("2 ", .{}); }if (false) {// defers are not run if they are never executed.defer { print("3 ", .{}); } }}test"defer unwinding" { deferUnwindExample();}// The errdefer keyword is similar to defer, but will only execute if the// scope returns with an error.//// This is especially useful in allowing a function to clean up properly// on error, and replaces goto error handling tactics as seen in c.fndeferErrorExample(is_error: bool) !void { print("\nstart of function\n", .{});// This will always be executed on exitdefer { print("end of function\n", .{}); }errdefer { print("encountered an error!\n", .{}); }if (is_error) {returnerror.DeferError; }}test"errdefer unwinding" { deferErrorExample(false) catch {}; deferErrorExample(true) catch {};}
Shell
$ zig test defer.zig1/3 test "defer basics"... OK2/3 test "defer unwinding"...2 1 OK3/3 test "errdefer unwinding"...start of functionend of functionstart of functionencountered an error!end of functionOKAll 3 tests passed.
In Debug and ReleaseSafe mode, and when using zig test,
unreachable emits a call to panic with the message reached unreachable code.
In ReleaseFast mode, the optimizer uses the assumption that unreachable code
will never be hit to perform optimizations. However, zig test even in ReleaseFast mode
still emits unreachable as calls to panic.
// 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.zig1/1 test "basic math"... OKAll 1 tests passed.
In fact, this is how std.debug.assert is implemented:
test.zig
// This is how std.debug.assert is implementedfnassert(ok: bool) void {if (!ok) unreachable; // assertion failure}// This test will fail because we hit unreachable.test"this will fail" { assert(false);}
Shell
$ zig test test.zig1/1 test "this will fail"... thread 1431741 panic: reached unreachable code/home/andy/tmp/zig/docgen_tmp/test.zig:3:14: 0x207dbb in assert (test) if (!ok) unreachable; // assertion failure^/home/andy/tmp/zig/docgen_tmp/test.zig:8:11: 0x20784e in test "this will fail" (test) assert(false);^/home/andy/tmp/zig/lib/std/special/test_runner.zig:80:28: 0x22f103 in std.special.main (test) } else test_fn.func();^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x22847c in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x2090be in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x208156 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x207f62 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^error: the following test command crashed:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
const assert = @import("std").debug.assert;test"type of unreachable" {comptime {// The type of unreachable is noreturn.// However this assertion will still fail to compile because// unreachable expressions are compile errors. assert(@TypeOf(unreachable) == noreturn); }}
Shell
$ zig test test.zigdocgen_tmp/test.zig:10:16: error: unreachable code
assert(@TypeOf(unreachable) == noreturn);^docgen_tmp/test.zig:10:24: note: control flow is diverted here
assert(@TypeOf(unreachable) == noreturn);^
const std = @import("std");const builtin = @import("builtin");const native_arch = builtin.cpu.arch;const expect = std.testing.expect;// Functions are declared like thisfnadd(a: i8, b: i8) i8 {if (a == 0) {return b; }return a + b;}// The export specifier makes a function externally visible in the generated// object file, and makes it use the C ABI.exportfnsub(a: i8, b: i8) i8 { return a - b; }// The extern specifier is used to declare a function that will be resolved// at link time, when linking statically, or at runtime, when linking// dynamically.// The callconv specifier changes the calling convention of the function.const WINAPI: std.builtin.CallingConvention = if (native_arch == .i386) .Stdcall else .C;extern"kernel32"fnExitProcess(exit_code: u32) callconv(WINAPI) noreturn;extern"c"fnatan2(a: f64, b: f64) f64;// The @setCold builtin tells the optimizer that a function is rarely called.fnabort() noreturn {@setCold(true);while (true) {}}// The naked calling convention makes a function not have any function prologue or epilogue.// This can be useful when integrating with assembly.fn_start() callconv(.Naked) noreturn { abort();}// The inline calling convention forces a function to be inlined at all call sites.// If the function cannot be inlined, it is a compile-time error.fnshiftLeftOne(a: u32) callconv(.Inline) u32 {return a << 1;}// The pub specifier allows the function to be visible when importing.// Another file can use @import and call sub2pubfnsub2(a: i8, b: i8) i8 { return a - b; }// Functions can be used as values and are equivalent to pointers.const call2_op = fn (a: i8, b: i8) i8;fndo_op(fn_call: call2_op, op1: i8, op2: i8) i8 {return fn_call(op1, op2);}test"function" {try expect(do_op(add, 5, 6) == 11);try expect(do_op(sub2, 5, 6) == -1);}
Shell
$ zig test functions.zig1/1 test "function"... OKAll 1 tests passed.
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.
pass_by_reference_or_value.zig
const Point = struct { x: i32, y: i32,};fnfoo(point: Point) i32 {// Here, `point` could be a reference, or a copy. The function body// can ignore the difference and treat it as a value. Be very careful// taking the address of the parameter - it should be treated as if// the address will become invalid when the function returns.return point.x + point.y;}const expect = @import("std").testing.expect;test"pass struct to function" {try expect(foo(Point{ .x = 1, .y = 2 }) == 3);}
Shell
$ zig test pass_by_reference_or_value.zig1/1 test "pass struct to function"... OKAll 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.
An error set is like an enum.
However, each error name across the entire compilation gets assigned an unsigned integer
greater than 0. You are allowed to declare the same error name more than once, and if you do, it
gets assigned the same integer value.
The number of unique error values across the entire compilation should determine the size of the error set type.
However right now it is hard coded to be a u16. See #768.
You can coerce an error from a subset to a superset:
$ zig test test.zig./docgen_tmp/test.zig:16:12: error: expected type 'AllocationError', found 'FileOpenError' return err;^./docgen_tmp/test.zig:2:5: note: 'error.AccessDenied' not a member of destination error set AccessDenied,^./docgen_tmp/test.zig:4:5: note: 'error.FileNotFound' not a member of destination error set FileNotFound,^
There is a shortcut for declaring an error set with only 1 value, and then getting that value:
anyerror refers to the global error set.
This is the error set that contains all errors in the entire compilation unit.
It is a superset of all other error sets and a subset of none of them.
You can coerce any error set to the global one, and you can explicitly
cast an error of the global error set to a non-global one. This inserts a language-level
assert to make sure the error value is in fact in the destination error set.
The global error set should generally be avoided because it prevents the
compiler from knowing what errors are possible at compile-time. Knowing
the error set at compile-time is better for generated documentation and
helpful error messages, such as forgetting a possible error value in a switch.
An error set type and normal type can be combined with the !
binary operator to form an error union type. You are likely to use an
error union type more often than an error set type by itself.
Here is a function to parse a string into a 64-bit integer:
$ zig test error_union_parsing_u64.zig1/1 test "parse u64"... OKAll 1 tests passed.
Notice the return type is !u64. This means that the function
either returns an unsigned 64 bit integer, or an error. We left off the error set
to the left of the !, so the error set is inferred.
Within the function definition, you can see some return statements that return
an error, and at the bottom a return statement that returns a u64.
Both types coerce to anyerror!u64.
What it looks like to use this function varies depending on what you're
trying to do. One of the following:
You want to provide a default value if it returned an error.
If it returned an error then you want to return the same error.
You know with complete certainty it will not return an error, so want to unconditionally unwrap it.
You want to take a different action for each possible error.
In this code, number will be equal to the successfully parsed string, or
a default value of 13. The type of the right hand side of the binary catch operator must
match the unwrapped error union type, or be of type noreturn.
try evaluates an error union expression. If it is an error, it returns
from the current function with the same error. Otherwise, the expression results in
the unwrapped value.
Maybe you know with complete certainty that an expression will never be an error.
In this case you can do this:
const number = parseU64("1234", 10) catchunreachable;
Here we know for sure that "1234" will parse successfully. So we put the
unreachable value on the right hand side. unreachable generates
a panic in Debug and ReleaseSafe modes and undefined behavior in ReleaseFast mode. So, while we're debugging the
application, if there was a surprise error here, the application would crash
appropriately.
Finally, you may want to take a different action for every situation. For that, we combine
the if and switch expression:
handle_all_error_scenarios.zig
fndoAThing(str: []u8) void {if (parseU64(str, 10)) |number| { doSomethingWithNumber(number); } else |err| switch (err) {error.Overflow => {// handle overflow... },// we promise that InvalidChar won't happen (or crash in debug mode if it does)error.InvalidChar => unreachable, }}
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
fncreateFoo(param: i32) !Foo {const foo = try tryToAllocateFoo();// now we have allocated foo. we need to free it if the function fails.// but we want to return it if the function succeeds.errdefer deallocateFoo(foo);const tmp_buf = allocateTmpBuffer() orelsereturnerror.OutOfMemory;// tmp_buf is truly a temporary resource, and we for sure want to clean it up// before this block leaves scopedefer deallocateTmpBuffer(tmp_buf);if (param > 1337) returnerror.InvalidParam;// here the errdefer will not run since we're returning success from the function.// but the defer will run!return foo;}
The neat thing about this is that you get robust error handling without
the verbosity and cognitive overhead of trying to make sure every exit path
is covered. The deallocation code is always directly following the allocation code.
A couple of other tidbits about error handling:
These primitives give enough expressiveness that it's completely practical
to have failing to check for an error be a compile error. If you really want
to ignore the error, you can add catchunreachable and
get the added benefit of crashing in Debug and ReleaseSafe modes if your assumption was wrong.
Since Zig understands error types, it can pre-weight branches in favor of
errors not occurring. Just a small optimization benefit that is not available
in other languages.
An error union is created with the ! 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;test"error union" {var foo: anyerror!i32 = undefined;// Coerce from child type of an error union: foo = 1234;// Coerce from an error set: foo = error.SomeError;// Use compile-time reflection to access the payload type of an error union:comptimetry expect(@typeInfo(@TypeOf(foo)).ErrorUnion.payload == i32);// Use compile-time reflection to access the error set type of an error union:comptimetry expect(@typeInfo(@TypeOf(foo)).ErrorUnion.error_set == anyerror);}
Shell
$ zig test test_error_union.zig1/1 test "error union"... OKAll 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,/// A doc comment PathNotFound,};const B = error{ OutOfMemory,/// B doc comment PathNotFound,};const C = A || B;fnfoo() C!void {returnerror.NotDir;}test"merge error sets" {if (foo()) {@panic("unexpected"); } else |err| switch (err) {error.OutOfMemory => @panic("unexpected"),error.PathNotFound => @panic("unexpected"),error.NotDir => {}, }}
Shell
$ zig test test_merging_error_sets.zig1/1 test "merge error sets"... OKAll 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:
inferred_error_sets.zig
// With an inferred error setpubfnadd_inferred(comptime T: type, a: T, b: T) !T {var answer: T = undefined;returnif (@addWithOverflow(T, a, b, &answer)) error.Overflow else answer;}// With an explicit error setpubfnadd_explicit(comptime T: type, a: T, b: T) Error!T {var answer: T = undefined;returnif (@addWithOverflow(T, a, b, &answer)) error.Overflow else answer;}const Error = error { Overflow,};const std = @import("std");test"inferred error set" {if (add_inferred(u8, 255, 1)) |_| unreachableelse |err| switch (err) {error.Overflow => {}, // ok }}
Shell
$ zig test inferred_error_sets.zig1/1 test "inferred error set"... OKAll 1 tests passed.
When a function has an inferred error set, that function becomes generic and thus it becomes
trickier to do certain things with it, such as obtain a function pointer, or have an error
set that is consistent across different build targets. Additionally, inferred error sets
are incompatible with recursion.
In these situations, it is recommended to use an explicit error set. You can generally start
with an empty error set and let compile errors guide you toward completing the set.
These limitations may be overcome in a future version of Zig.
Error Return Traces 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.
$ zig build-exe test.zig$ ./testerror: PermissionDenied/home/andy/tmp/zig/docgen_tmp/test.zig:39:5: 0x234472 in bang1 (test) return error.FileNotFound;^/home/andy/tmp/zig/docgen_tmp/test.zig:23:5: 0x23434f in baz (test) try bang1();^/home/andy/tmp/zig/docgen_tmp/test.zig:43:5: 0x234312 in bang2 (test) return error.PermissionDenied;^/home/andy/tmp/zig/docgen_tmp/test.zig:31:5: 0x23443f in hello (test) try bang2();^/home/andy/tmp/zig/docgen_tmp/test.zig:17:31: 0x2342de in bar (test) error.FileNotFound => try hello(),^/home/andy/tmp/zig/docgen_tmp/test.zig:7:9: 0x2341cc in foo (test) try bar();^/home/andy/tmp/zig/docgen_tmp/test.zig:2:5: 0x22ceb4 in main (test) try foo(12);^
Look closely at this example. This is no stack trace.
You can see that the final error bubbled up was PermissionDenied,
but the original error that started this whole thing was FileNotFound. In the bar function, the code handles the original error code,
and then returns another one, from the switch statement. Error Return Traces make this clear, whereas a stack trace would look like this:
$ zig build-exe test.zig$ ./testthread 1434232 panic: PermissionDenied/home/andy/tmp/zig/docgen_tmp/test.zig:38:5: 0x234f66 in bang2 (test) @panic("PermissionDenied");^/home/andy/tmp/zig/docgen_tmp/test.zig:30:10: 0x2352e8 in hello (test) bang2();^/home/andy/tmp/zig/docgen_tmp/test.zig:17:14: 0x234f4a in bar (test) hello();^/home/andy/tmp/zig/docgen_tmp/test.zig:7:12: 0x233f75 in foo (test) bar();^/home/andy/tmp/zig/docgen_tmp/test.zig:2:8: 0x22cccd in main (test) foo(12);^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x2263dc in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x206ffe in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x206096 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x205ea2 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^(process terminated by signal)
Here, the stack trace does not explain how the control
flow in bar got to the hello() call.
One would have to open a debugger or further instrument the application
in order to find out. The error return trace, on the other hand,
shows exactly how the error bubbled up.
This debugging feature makes it easier to iterate quickly on code that
robustly handles all error conditions. This means that Zig developers
will naturally find themselves writing correct, robust code in order
to increase their development pace.
There are a few ways to activate this error return tracing feature:
Return an error from main
An error makes its way to catchunreachable and you have not overridden the default panic handler
Use errorReturnTrace to access the current return trace. You can use std.debug.dumpStackTrace to print it. This function returns comptime-known null when building without error return tracing support.
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:
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 IRfn__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.
Now the variable optional_int could be an i32, or null.
Instead of integers, let's talk about pointers. Null references are the source of many runtime
exceptions, and even stand accused of being
the worst mistake of computer science.
Zig does not have them.
Instead, you can use an optional pointer. This secretly compiles down to a normal pointer,
since we know we can use 0 as the null value for the optional type. But the compiler
can check your work and make sure you don't assign null to something that can't be null.
Typically the downside of not having null is that it makes the code more verbose to
write. But, let's compare some equivalent C code and Zig code.
Task: call malloc, if the result is null, return null.
C code
call_malloc_in_c.c
// malloc prototype included for referencevoid *malloc(size_t size);struct Foo *do_a_thing(void) { char *ptr = malloc(1234); if (!ptr) return NULL; // ...}
Zig code
call_malloc_from_zig.zig
// malloc prototype included for referenceexternfnmalloc(size: size_t) ?*u8;fndoAThing() ?*Foo {const ptr = malloc(1234) orelsereturnnull; _ = ptr; // ...}
Here, Zig is at least as convenient, if not more, than C. And, the type of "ptr"
is *u8not?*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}
In Zig you can accomplish the same thing:
checking_null_in_zig.zig
const Foo = struct{};fndoSomethingWithFoo(foo: *Foo) void { _ = foo; }fndoAThing(optional_foo: ?*Foo) void {// do some stuffif (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.
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;test"optional type" {// Declare an optional and coerce from null:var foo: ?i32 = null;// Coerce from child type of an optional foo = 1234;// Use compile-time reflection to access the child type of the optional:comptimetry expect(@typeInfo(@TypeOf(foo)).Optional.child == i32);}
Shell
$ zig test test_optional_type.zig1/1 test "optional type"... OKAll 1 tests passed.
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;test"optional pointers" {// Pointers cannot be null. If you want a null pointer, use the optional// prefix `?` to make the pointer type optional.var ptr: ?*i32 = null;var x: i32 = 1; ptr = &x;try expect(ptr.?.* == 1);// Optional pointers are the same size as normal pointers, because pointer// value 0 is used as the null value.try expect(@sizeOf(?*i32) == @sizeOf(*i32));}
Shell
$ zig test test_optional_pointer.zig1/1 test "optional pointers"... OKAll 1 tests passed.
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.
$ zig test type_coercion.zig1/3 test "type coercion - variable declaration"... OK2/3 test "type coercion - function call"... OK3/3 test "type coercion - @as builtin"... OKAll 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:
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" {var a: u8 = 250;var b: u16 = a;var c: u32 = b;var d: u64 = c;var e: u64 = d;var f: u128 = e;try expect(f == a);}test"implicit unsigned integer to signed integer" {var a: u8 = 250;var b: i16 = a;try expect(b == 250);}test"float widening" {// Note: there is an open issue preventing this from working on aarch64:// https://github.com/ziglang/zig/issues/3282if (builtin.target.cpu.arch == .aarch64) returnerror.SkipZigTest;var a: f16 = 12.34;var b: f32 = a;var c: f64 = b;var d: f128 = c;try expect(d == a);}
Shell
$ zig test test_integer_widening.zig1/3 test "integer widening"... OK2/3 test "implicit unsigned integer to signed integer"... OK3/3 test "float widening"... OKAll 3 tests passed.
const std = @import("std");const expect = std.testing.expect;// You can assign constant pointers to arrays to a slice with// const modifier on the element type. Useful in particular for// String literals.test"*const [N]T to []const T" {var x1: []constu8 = "hello";var x2: []constu8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };try expect(std.mem.eql(u8, x1, x2));var y: []constf32 = &[2]f32{ 1.2, 3.4 };try expect(y[0] == 1.2);}// Likewise, it works when the destination type is an error union.test"*const [N]T to E![]const T" {var x1: anyerror![]constu8 = "hello";var x2: anyerror![]constu8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };try expect(std.mem.eql(u8, try x1, try x2));var y: anyerror![]constf32 = &[2]f32{ 1.2, 3.4 };try expect((try y)[0] == 1.2);}// Likewise, it works when the destination type is an optional.test"*const [N]T to ?[]const T" {var x1: ?[]constu8 = "hello";var x2: ?[]constu8 = &[5]u8{ 'h', 'e', 'l', 'l', 111 };try expect(std.mem.eql(u8, x1.?, x2.?));var y: ?[]constf32 = &[2]f32{ 1.2, 3.4 };try expect(y.?[0] == 1.2);}// In this cast, the array length becomes the slice length.test"*[N]T to []T" {var buf: [5]u8 = "hello".*;const x: []u8 = &buf;try expect(std.mem.eql(u8, x, "hello"));const buf2 = [2]f32{ 1.2, 3.4 };const x2: []constf32 = &buf2;try expect(std.mem.eql(f32, x2, &[2]f32{ 1.2, 3.4 }));}// Single-item pointers to arrays can be coerced to many-item pointers.test"*[N]T to [*]T" {var buf: [5]u8 = "hello".*;const x: [*]u8 = &buf;try expect(x[4] == 'o');// x[5] would be an uncaught out of bounds pointer dereference!}// Likewise, it works when the destination type is an optional.test"*[N]T to ?[*]T" {var buf: [5]u8 = "hello".*;const x: ?[*]u8 = &buf;try expect(x.?[4] == 'o');}// Single-item pointers can be cast to len-1 single-item arrays.test"*T to *[1]T" {var x: i32 = 1234;const y: *[1]i32 = &x;const z: [*]i32 = y;try expect(z[0] == 1234);}
Shell
$ zig test coerce__slices_arrays_and_ptrs.zig1/7 test "*const [N]T to []const T"... OK2/7 test "*const [N]T to E![]const T"... OK3/7 test "*const [N]T to ?[]const T"... OK4/7 test "*[N]T to []T"... OK5/7 test "*[N]T to [*]T"... OK6/7 test "*[N]T to ?[*]T"... OK7/7 test "*T to *[1]T"... OKAll 7 tests passed.
When a number is comptime-known to be representable in the destination type,
it may be coerced:
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 known to fit" {const x: u64 = 255;const y: u8 = x;try expect(y == 255);}
Shell
$ zig test test_coerce_large_to_small.zig1/1 test "coercing large integer type to smaller one when value is comptime known to fit"... OKAll 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,};test"coercion between unions and enums" {var u = U{ .two = 12.34 };var e: E = u;try expect(e == E.two);const three = E.three;var another_u: U = three;try expect(another_u == E.three);}
Shell
$ zig test test_coerce_unions_enums.zig1/1 test "coercion between unions and enums"... OKAll 1 tests passed.
Explicit casts are performed via Builtin Functions.
Some explicit casts are safe; some are not.
Some explicit casts perform language-level assertions; some do not.
Some explicit casts are no-ops at runtime; some are not.
@bitCast - change type but maintain bit representation
$ zig test peer_type_resolution.zig1/7 test "peer resolve int widening"... OK2/7 test "peer resolve arrays of different size to const slice"... OK3/7 test "peer resolve array and const slice"... OK4/7 test "peer type resolution: ?T and T"... OK5/7 test "peer type resolution: *[0]u8 and []const u8"... OK6/7 test "peer type resolution: *[0]u8, []const u8, and anyerror![]u8"... OK7/7 test "peer type resolution: *const T and ?*T"... OKAll 7 tests passed.
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:
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:
void_in_hashmap.zig
const std = @import("std");const expect = std.testing.expect;test"turn HashMap into a set with void" {var map = std.AutoHashMap(i32, void).init(std.testing.allocator);defer map.deinit();try map.put(1, {});try map.put(2, {});try expect(map.contains(2));try expect(!map.contains(3)); _ = map.remove(2);try expect(!map.contains(2));}
Shell
$ zig test void_in_hashmap.zig1/1 test "turn HashMap into a set with void"... OKAll 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:
Pointers to zero bit types also have zero bits. They always compare equal to each other:
pointers_to_zero_bits.zig
const std = @import("std");const expect = std.testing.expect;test"pointer to empty struct" {const Empty = struct {};var a = Empty{};var b = Empty{};var ptr_a = &a;var ptr_b = &b;comptimetry expect(ptr_a == ptr_b);}
Shell
$ zig test pointers_to_zero_bits.zig1/1 test "pointer to empty struct"... OKAll 1 tests passed.
The type being pointed to can only ever be one value; therefore loads and stores are
never generated. ptrToInt and intToPtr are not allowed:
test.zig
const Empty = struct {};test"@ptrToInt for pointer to zero bit type" {var a = Empty{}; _ = @ptrToInt(&a);}test"@intToPtr for pointer to zero bit type" { _ = @intToPtr(*Empty, 0x1);}
Shell
$ zig test test.zig./docgen_tmp/test.zig:4:5: error: pointer to size 0 type has no address var a = Empty{};^./docgen_tmp/test.zig:9:19: error: type '*Empty' has 0 bits and cannot store information _ = @intToPtr(*Empty, 0x1);^
usingnamespace is a declaration that mixes all the public
declarations of the operand, which must be a struct, union, enum,
or opaque, into the namespace:
usingnamespace.zig
test"using std namespace" {const S = struct {usingnamespace@import("std"); };try S.testing.expect(true);}
Shell
$ zig test usingnamespace.zig1/1 test "using std namespace"... OKAll 1 tests passed.
usingnamespace has an important use case when organizing the public
API of a file or package. For example, one might have c.zig with all of the
C imports:
The above example demonstrates using pub to qualify the
usingnamespace additionally makes the imported declarations
pub. This can be used to forward declarations, giving precise control
over what declarations a given file exposes.
Zig places importance on the concept of whether an expression is known at compile-time.
There are a few different places this concept is used, and these building blocks are used
to keep the language small, readable, and powerful.
Compile-time parameters is how Zig implements generics. It is compile-time duck typing.
test.zig
fnmax(comptime T: type, a: T, b: T) T {returnif (a > b) a else b;}fngimmeTheBiggerFloat(a: f32, b: f32) f32 {return max(f32, a, b);}fngimmeTheBiggerInteger(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.
A comptime parameter means that:
At the callsite, the value must be known at compile-time, or it is a compile error.
In the function definition, the value is known at compile-time.
For example, if we were to introduce another function to the above snippet:
test.zig
fnmax(comptime T: type, a: T, b: T) T {returnif (a > b) a else b;}test"try to pass a runtime type" { foo(false);}fnfoo(condition: bool) void {const result = max(if (condition) f32elseu64,1234,5678); _ = result;}
Shell
$ zig test test.zig./docgen_tmp/test.zig:9:9: error: values of type 'type' must be comptime known if (condition) f32 else u64,^
This is an error because the programmer attempted to pass a value only known at run-time
to a function which expects a value known at compile-time.
Another way to get an error is if we pass a type that violates the type checker when the
function is analyzed. This is what it means to have compile-time duck typing.
For example:
test.zig
fnmax(comptime T: type, a: T, b: T) T {returnif (a > b) a else b;}test"try to compare bools" { _ = max(bool, true, false);}
Shell
$ zig test test.zig./docgen_tmp/test.zig:2:18: error: operator not allowed for type 'bool' return if (a > b) a else b;^./docgen_tmp/test.zig:5:12: note: called from here _ = max(bool, true, false);^./docgen_tmp/test.zig:4:29: note: called from heretest "try to compare bools" {^
On the flip side, inside the function definition with the comptime parameter, the
value is known at compile-time. This means that we actually could make this work for the bool type
if we wanted to:
comptime_max_with_bool.zig
fnmax(comptime T: type, a: T, b: T) T {if (T == bool) {return a or b; } elseif (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 comptime_max_with_bool.zig1/1 test "try to compare bools"... OKAll 1 tests passed.
This works because Zig implicitly inlines if expressions when the condition
is known at compile-time, and the compiler guarantees that it will skip analysis of
the branch not taken.
This means that the actual function generated for max in this situation looks like
this:
test.zig
fnmax(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.
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.
$ zig test comptime_vars.zig1/1 test "perform fn"... OKAll 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);fnperformFn(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);fnperformFn(start_value: i32) i32 {var result: i32 = start_value; result = one(result);return result;}
performFn_3
// From the line:// expect(performFn('w', 99) == 99);fnperformFn(start_value: i32) i32 {var result: i32 = start_value;return result;}
Note that this happens even in a debug build; in a release build these generated functions still
pass through rigorous LLVM optimizations. The important thing to note, however, is not that this
is a way to write more optimized code, but that it is a way to make sure that what should happen
at compile-time, does happen at compile-time. This catches more errors and as demonstrated
later in this article, allows expressiveness that in other languages requires using macros,
generated code, or a preprocessor to accomplish.
In Zig, it matters whether a given expression is known at compile-time or run-time. A programmer can
use a comptime expression to guarantee that the expression will be evaluated at compile-time.
If this cannot be accomplished, the compiler will emit an error. For example:
$ zig test test.zig./docgen_tmp/test.zig:5:9: error: unable to evaluate constant expression exit();^
It doesn't make sense that a program could call exit() (or any other external function)
at compile-time, so this is a compile error. However, a comptime expression does much
more than sometimes cause a compile error.
Within a comptime expression:
All variables are comptime variables.
All if, while, for, and switch
expressions are evaluated at compile-time, or emit a compile error if this is not possible.
All function calls cause the compiler to interpret the function at compile-time, emitting a
compile error if the function tries to do something that has global run-time side effects.
This means that a programmer can create a function which is called both at compile-time and run-time, with
no modification to the function required.
Let's look at an example:
fibonacci_recursion.zig
const expect = @import("std").testing.expect;fnfibonacci(index: u32) u32 {if (index < 2) return index;return fibonacci(index - 1) + fibonacci(index - 2);}test"fibonacci" {// test fibonacci at run-timetry expect(fibonacci(7) == 13);// test fibonacci at compile-timecomptime {try expect(fibonacci(7) == 13); }}
Shell
$ zig test fibonacci_recursion.zig1/1 test "fibonacci"... OKAll 1 tests passed.
Imagine if we had forgotten the base case of the recursive function and tried to run the tests:
$ zig test test.zig./docgen_tmp/test.zig:5:28: error: operation caused overflow return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:10:29: note: called from here try expect(fibonacci(7) == 13);^./docgen_tmp/test.zig:8:18: note: called from heretest "fibonacci" {^
The compiler produces an error which is a stack trace from trying to evaluate the
function at compile-time.
Luckily, we used an unsigned integer, and so when we tried to subtract 1 from 0, it triggered
undefined behavior, which is always a compile error if the compiler knows it happened.
But what would have happened if we used a signed integer?
$ zig test test.zig./docgen_tmp/test.zig:5:21: error: evaluation exceeded 1000 backwards branches return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^./docgen_tmp/test.zig:5:21: note: called from here return fibonacci(index - 1) + fibonacci(index - 2);^
The compiler noticed that evaluating this function at compile-time took a long time,
and thus emitted a compile error and gave up. If the programmer wants to increase
the budget for compile-time computation, they can use a built-in function called
@setEvalBranchQuota to change the default number 1000 to something else.
What if we fix the base case, but put the wrong value in the expect line?
$ zig test test.zig1/1 test "fibonacci"... test "fibonacci"... FAIL (TestUnexpectedResult)FAIL (TestUnexpectedResult)0 passed; 0 skipped; 1 failed.error: the following test command failed with exit code 1:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
What happened is Zig started interpreting the expect function with the
parameter ok set to false. When the interpreter hit
@panic it emitted a compile error because a panic during compile
causes a compile error if it is detected at compile-time.
At container level (outside of any function), all expressions are implicitly
comptime expressions. This means that we can use functions to
initialize complex static data. For example:
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 these capabilities to implement generic data structures without introducing any
special-case syntax. If you followed along so far, you may already know how to create a
generic data structure.
Here is an example of a generic List data structure.
test.zig
fnList(comptime T: type) type {returnstruct { items: []T, len: usize, };}// The generic List data structure can be instantiated by passing in a type:var buffer: [10]i32 = undefined;var list = List(i32){ .items = &buffer, .len = 0,};
That's it. It's a function that returns an anonymous struct.
To keep the language small and uniform, all aggregate types in Zig are anonymous.
For the purposes of error messages and debugging, Zig infers the name
"List(i32)" from the function name and parameters invoked when creating
the anonymous struct.
To explicitly give a type a name, we assign it to a constant.
In this example, the Node struct refers to itself.
This works because all top level declarations are order-independent.
As long as the compiler can determine the size of the struct, it is free to refer to itself.
In this case, Node refers to itself as a pointer, which has a
well-defined size at compile time, so it works fine.
Putting all of this together, let's see how print works in Zig.
print.zig
const print = @import("std").debug.print;const a_number: i32 = 1234;const a_string = "foobar";pubfnmain() void { print("here is a string: '{s}' here is a number: {}\n", .{a_string, a_number});}
Shell
$ zig build-exe print.zig$ ./printhere is a string: 'foobar' here is a number: 1234
Let's crack open the implementation of this and see how it works:
This is a proof of concept implementation; the actual function in the standard library has more
formatting capabilities.
Note that this is not hard-coded into the Zig compiler; this is userland code in the standard library.
When this function is analyzed from our example code above, Zig partially evaluates the function
and emits a function that actually looks like this:
Emitted print Function
pubfnprint(self: *Writer, arg0: []constu8, arg1: i32) !void {try self.write("here is a string: '");try self.printValue(arg0);try self.write("' here is a number: ");try self.printValue(arg1);try self.write("\n");try self.flush();}
printValue is a function that takes a parameter of any type, and does different things depending
on the type:
And now, what happens if we give too many arguments to print?
test.zig
const print = @import("std").debug.print;const a_number: i32 = 1234;const a_string = "foobar";test"print too many arguments" { print("here is a string: '{s}' here is a number: {}\n", .{ a_string, a_number, a_number, });}
Shell
$ zig test test.zig./lib/std/fmt.zig:197:18: error: Unused argument in 'here is a string: '{s}' here is a number: {}' 1 => @compileError("Unused argument in '" ++ fmt ++ "'"),^./lib/std/io/writer.zig:28:34: note: called from here return std.fmt.format(self, format, args);^./lib/std/debug.zig:67:27: note: called from here nosuspend stderr.print(fmt, args) catch return;^./docgen_tmp/test.zig:7:10: note: called from here print("here is a string: '{s}' here is a number: {}\n", .{^./docgen_tmp/test.zig:6:33: note: called from heretest "print too many arguments" {^./lib/std/io/writer.zig:28:34: error: expected type 'std.os.WriteError!void', found '@typeInfo(@typeInfo(@TypeOf(std.fmt.format)).Fn.return_type.?).ErrorUnion.error_set!void' return std.fmt.format(self, format, args);^./lib/std/debug.zig:67:27: note: called from here nosuspend stderr.print(fmt, args) catch return;^./docgen_tmp/test.zig:7:10: note: called from here print("here is a string: '{s}' here is a number: {}\n", .{^./docgen_tmp/test.zig:6:33: note: called from heretest "print too many arguments" {^./lib/std/io/writer.zig:28:34: note: error set '@typeInfo(@typeInfo(@TypeOf(std.fmt.format)).Fn.return_type.?).ErrorUnion.error_set' cannot cast into error set 'std.os.WriteError' return std.fmt.format(self, format, args);^
Zig gives programmers the tools needed to protect themselves against their own mistakes.
Zig doesn't care whether the format argument is a string literal,
only that it is a compile-time known value that can be coerced to a []constu8:
print.zig
const print = @import("std").debug.print;const a_number: i32 = 1234;const a_string = "foobar";const fmt = "here is a string: '{s}' here is a number: {}\n";pubfnmain() void { print(fmt, .{a_string, a_number});}
Shell
$ zig build-exe print.zig$ ./printhere is a string: 'foobar' here is a number: 1234
This works fine.
Zig does not special case string formatting in the compiler and instead exposes enough power to accomplish this
task in userland. It does so without introducing another language on top of Zig, such as
a macro language or a preprocessor language. It's Zig all the way down.
For some use cases, it may be necessary to directly control the machine code generated
by Zig programs, rather than relying on Zig's code generation. For these cases, one
can use inline assembly. Here is an example of implementing Hello, World on x86_64 Linux
using inline assembly:
$ zig build-exe test.zig -target x86_64-linux$ ./testhello world
Dissecting the syntax:
Assembly Syntax Explained
// Inline assembly is an expression which returns a value.// the `asm` keyword begins the expression._ = asm// `volatile` is an optional modifier that tells Zig this// inline assembly expression has side-effects. Without// `volatile`, Zig is allowed to delete the inline assembly// code if the result is unused.volatile (// Next is a comptime string which is the assembly code.// Inside this string one may use `%[ret]`, `%[number]`,// or `%[arg1]` where a register is expected, to specify// the register that Zig uses for the argument or return value,// if the register constraint strings are used. However in// the below code, this is not used. A literal `%` can be// obtained by escaping it with a double percent: `%%`.// Often multiline string syntax comes in handy here.\\syscall// Next is the output. It is possible in the future Zig will// support multiple outputs, depending on how// https://github.com/ziglang/zig/issues/215 is resolved.// It is allowed for there to be no outputs, in which case// this colon would be directly followed by the colon for the inputs. :// This specifies the name to be used in `%[ret]` syntax in// the above assembly string. This example does not use it,// but the syntax is mandatory. [ret]// Next is the output constraint string. This feature is still// considered unstable in Zig, and so LLVM/GCC documentation// must be used to understand the semantics.// http://releases.llvm.org/10.0.0/docs/LangRef.html#inline-asm-constraint-string// https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html// In this example, the constraint string means "the result value of// this inline assembly instruction is whatever is in $rax"."={rax}"// Next is either a value binding, or `->` and then a type. The// type is the result type of the inline assembly expression.// If it is a value binding, then `%[ret]` syntax would be used// to refer to the register bound to the value. (-> usize)// Next is the list of inputs.// The constraint for these inputs means, "when the assembly code is// executed, $rax shall have the value of `number` and $rdi shall have// the value of `arg1`". Any number of input parameters is allowed,// including none. : [number] "{rax}" (number), [arg1] "{rdi}" (arg1)// Next is the list of clobbers. These declare a set of registers whose// values will not be preserved by the execution of this assembly code.// These do not include output or input registers. The special clobber// value of "memory" means that the assembly writes to arbitrary undeclared// memory locations - not only the memory pointed to by a declared indirect// output. In this example we list $rcx and $r11 because it is known the// kernel syscall does not preserve these registers. : "rcx", "r11");
For i386 and x86_64 targets, the syntax is AT&T syntax, rather than the more
popular Intel syntax. This is due to technical constraints; assembly parsing is
provided by LLVM and its support for Intel syntax is buggy and not well tested.
Some day Zig may have its own assembler. This would allow it to integrate more seamlessly
into the language, as well as be compatible with the popular NASM syntax. This documentation
section will be updated before 1.0.0 is released, with a conclusive statement about the status
of AT&T vs Intel/NASM syntax.
Output constraints are still considered to be unstable in Zig, and
so
LLVM documentation
and
GCC documentation
must be used to understand the semantics.
Note that some breaking changes to output constraints are planned with
issue #215.
Input constraints are still considered to be unstable in Zig, and
so
LLVM documentation
and
GCC documentation
must be used to understand the semantics.
Note that some breaking changes to input constraints are planned with
issue #215.
Clobbers are the set of registers whose values will not be preserved by the execution of
the assembly code. These do not include output or input registers. The special clobber
value of "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 Undefined Behavior.
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.
When a function is called, a frame is pushed to the stack,
the function runs until it reaches a return statement, and then the frame is popped from the stack.
The code following the callsite does not run until the function returns.
An async function is a function whose execution is split into an async initiation,
followed by an await completion. Its frame is
provided explicitly by the caller, and it can be suspended and resumed any number of times.
The code following the async callsite runs immediately after the async
function first suspends. When the return value of the async function is needed,
the calling code can await on the async function frame.
This will suspend the calling code until the async function completes, at which point
execution resumes just after the await callsite.
Zig infers that a function is async when it observes that the function contains
a suspension point. Async functions can be called the same as normal functions. A
function call of an async function is a suspend point.
At any point, a function may suspend itself. This causes control flow to
return to the callsite (in the case of the first suspension),
or resumer (in the case of subsequent suspensions).
suspend_no_resume.zig
const std = @import("std");const expect = std.testing.expect;var x: i32 = 1;test"suspend with no resume" {var frame = async func();try expect(x == 2); _ = frame;}fnfunc() void { x += 1;suspend {}// This line is never reached because the suspend has no matching resume. x += 1;}
Shell
$ zig test suspend_no_resume.zig1/1 test "suspend with no resume"... OKAll 1 tests passed.
In the same way that each allocation should have a corresponding free,
Each suspend should have a corresponding resume.
A suspend block allows a function to put a pointer to its own
frame somewhere, for example into an event loop, even if that action will perform a
resume operation on a different thread.
@frame provides access to the async function frame pointer.
async_suspend_block.zig
const std = @import("std");const expect = std.testing.expect;var the_frame: anyframe = undefined;var result = false;test"async function suspend with block" { _ = async testSuspendBlock();try expect(!result);resume the_frame;try expect(result);}fntestSuspendBlock() void {suspend {comptimetry expect(@TypeOf(@frame()) == *@Frame(testSuspendBlock)); the_frame = @frame(); } result = true;}
Shell
$ zig test async_suspend_block.zig1/1 test "async function suspend with block"... OKAll 1 tests passed.
Upon entering a suspend block, the async function is already considered
suspended, and can be resumed. For example, if you started another kernel thread,
and had that thread call resume on the frame pointer provided by the
@frame, the new thread would begin executing after the suspend
block, while the old thread continued executing the suspend block.
However, the async function can be directly resumed from the suspend block, in which case it
never returns to its resumer and continues executing.
In the same way that every suspend has a matching
resume, every async has a matching await
in standard code.
However, it is possible to have an async call
without a matching await. Upon completion of the async function,
execution would continue at the most recent async callsite or resume callsite,
and the return value of the async function would be lost.
async_await.zig
const std = @import("std");const expect = std.testing.expect;test"async and await" {// The test block is not async and so cannot have a suspend// point in it. By using the nosuspend keyword, we promise that// the code in amain will finish executing without suspending// back to the test block.nosuspend amain();}fnamain() void {var frame = async func();comptimetry expect(@TypeOf(frame) == @Frame(func));const ptr: anyframe->void = &frame;const any_ptr: anyframe = ptr;resume any_ptr;await ptr;}fnfunc() void {suspend {}}
Shell
$ zig test async_await.zig1/1 test "async and await"... OKAll 1 tests passed.
The await keyword is used to coordinate with an async function's
return statement.
await is a suspend point, and takes as an operand anything that
coerces to anyframe->T. Calling await on
the frame of an async function will cause execution to continue at the
await callsite once the target function completes.
There is a common misconception that await resumes the target function.
It is the other way around: it suspends until the target function completes.
In the event that the target function has already completed, await
does not suspend; instead it copies the
return value directly from the target function's frame.
$ zig test async_await_sequence.zig1/1 test "async function await"... OKAll 1 tests passed.
In general, suspend is lower level than await. Most application
code will use only async and await, but event loop
implementations will make use of suspend internally.
Putting all of this together, here is an example of typical
async/await usage:
async.zig
const std = @import("std");const Allocator = std.mem.Allocator;pubfnmain() void { _ = async amainWrap();// Typically we would use an event loop to manage resuming async functions,// but in this example we hard code what the event loop would do,// to make things deterministic.resume global_file_frame;resume global_download_frame;}fnamainWrap() void { amain() catch |e| { std.debug.print("{}\n", .{e});if (@errorReturnTrace()) |trace| { std.debug.dumpStackTrace(trace.*); } std.process.exit(1); };}fnamain() !void {const allocator = std.heap.page_allocator;var download_frame = async fetchUrl(allocator, "https://example.com/");var awaited_download_frame = false;errdeferif (!awaited_download_frame) {if (await download_frame) |r| allocator.free(r) else |_| {} };var file_frame = async readFile(allocator, "something.txt");var awaited_file_frame = false;errdeferif (!awaited_file_frame) {if (await file_frame) |r| allocator.free(r) else |_| {} }; awaited_file_frame = true;const file_text = tryawait file_frame;defer allocator.free(file_text); awaited_download_frame = true;const download_text = tryawait download_frame;defer allocator.free(download_text); std.debug.print("download_text: {s}\n", .{download_text}); std.debug.print("file_text: {s}\n", .{file_text});}var global_download_frame: anyframe = undefined;fnfetchUrl(allocator: Allocator, url: []constu8) ![]u8 { _ = url; // this is just an example, we don't actually do it!const result = try allocator.dupe(u8, "this is the downloaded url contents");errdefer allocator.free(result);suspend { global_download_frame = @frame(); } std.debug.print("fetchUrl returning\n", .{});return result;}var global_file_frame: anyframe = undefined;fnreadFile(allocator: Allocator, filename: []constu8) ![]u8 { _ = filename; // this is just an example, we don't actually do it!const result = try allocator.dupe(u8, "this is the file contents");errdefer allocator.free(result);suspend { global_file_frame = @frame(); } std.debug.print("readFile returning\n", .{});return result;}
Shell
$ zig build-exe async.zig$ ./asyncreadFile returningfetchUrl returningdownload_text: this is the downloaded url contentsfile_text: this is the file contents
Now we remove the suspend and resume code, and
observe the same behavior, with one tiny difference:
blocking.zig
const std = @import("std");const Allocator = std.mem.Allocator;pubfnmain() void { _ = async amainWrap();}fnamainWrap() void { amain() catch |e| { std.debug.print("{}\n", .{e});if (@errorReturnTrace()) |trace| { std.debug.dumpStackTrace(trace.*); } std.process.exit(1); };}fnamain() !void {const allocator = std.heap.page_allocator;var download_frame = async fetchUrl(allocator, "https://example.com/");var awaited_download_frame = false;errdeferif (!awaited_download_frame) {if (await download_frame) |r| allocator.free(r) else |_| {} };var file_frame = async readFile(allocator, "something.txt");var awaited_file_frame = false;errdeferif (!awaited_file_frame) {if (await file_frame) |r| allocator.free(r) else |_| {} }; awaited_file_frame = true;const file_text = tryawait file_frame;defer allocator.free(file_text); awaited_download_frame = true;const download_text = tryawait download_frame;defer allocator.free(download_text); std.debug.print("download_text: {s}\n", .{download_text}); std.debug.print("file_text: {s}\n", .{file_text});}fnfetchUrl(allocator: Allocator, url: []constu8) ![]u8 { _ = url; // this is just an example, we don't actually do it!const result = try allocator.dupe(u8, "this is the downloaded url contents");errdefer allocator.free(result); std.debug.print("fetchUrl returning\n", .{});return result;}fnreadFile(allocator: Allocator, filename: []constu8) ![]u8 { _ = filename; // this is just an example, we don't actually do it!const result = try allocator.dupe(u8, "this is the file contents");errdefer allocator.free(result); std.debug.print("readFile returning\n", .{});return result;}
Shell
$ zig build-exe blocking.zig$ ./blockingfetchUrl returningreadFile returningdownload_text: this is the downloaded url contentsfile_text: this is the file contents
Previously, the fetchUrl and readFile functions suspended,
and were resumed in an order determined by the main function. Now,
since there are no suspend points, the order of the printed "... returning" messages
is determined by the order of async callsites.
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.
Performs result.* = a + b. If overflow or underflow occurs,
stores the overflowed bits in result and returns true.
If no overflow or underflow occurs, returns false.
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.
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.
@asyncCall performs an async call on a function pointer,
which may or may not be an async function.
The provided frame_buffer must be large enough to fit the entire function frame.
This size can be determined with @frameSize. To provide a too-small buffer
invokes safety-checked Undefined Behavior.
result_ptr is optional (null may be provided). If provided,
the function call will write its result directly to the result pointer, which will be available to
read after await completes. Any result location provided to
await will copy the result from result_ptr.
Asserts that @sizeOf(@TypeOf(value)) == @sizeOf(DestType).
Asserts that @typeInfo(DestType) != .Pointer. Use @ptrCast or @intToPtr if you need this.
Can be used for these things for example:
Convert f32 to u32 bits
Convert i32 to u32 preserving twos complement
Works at compile-time if value is known at compile time. It's a compile error to bitcast a struct to a scalar type of the same size since structs have undefined layout. However if the struct is packed then it works.
Returns the bit offset of a field relative to its containing struct.
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.
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.
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.
$ zig test call.zig1/1 test "noinline function call"... OKAll 1 tests passed.
@call allows more flexibility than normal function call syntax does. The
CallOptions struct is reproduced here:
builtin.CallOptions struct
pubconst CallOptions = struct { modifier: Modifier = .auto,/// Only valid when `Modifier` is `Modifier.async_kw`. stack: ?[]align(std.Target.stack_align) u8 = null,pubconst Modifier = enum {/// Equivalent to function call syntax. auto,/// Equivalent to async keyword used with function call syntax. async_kw,/// 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 optimization./// If this is not possible, a compile error is emitted instead. always_tail,/// Guarantees that the call will inlined at the callsite./// If this is not possible, a compile error is emitted instead. always_inline,/// Evaluates the call at compile-time. If the call cannot be completed at/// compile-time, a compile error is emitted instead. compile_time, };};
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.
expression is interpreted at compile time. The builtin functions
@cInclude, @cDefine, and @cUndef work
within this expression, appending to a temporary buffer which is then parsed as C code.
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.
Reasons for having multiple @cImport expressions would be:
To avoid a symbol collision, for example if foo.h and bar.h both #define CONNECTION_COUNT
To analyze the C code with different preprocessor defines
This function counts the number of most-significant (leading in a big-Endian sense) zeroes in an integer.
If operand is a comptime-known integer,
the return type is comptime_int.
Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number
of bits that can represent the bit count of the integer type.
If operand is zero, @clz returns the bit width
of integer type T.
If you are using cmpxchg in a 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.
T must be a pointer, a bool, a float,
an integer or an enum.
@typeInfo(@TypeOf(ptr)).Pointer.alignment must be >= @sizeOf(T).
This function prints the arguments passed to it at compile-time.
To prevent accidentally leaving compile log statements in a codebase,
a compilation error is added to the build, pointing to the compile
log statement. This error prevents code from being generated, but
does not otherwise interfere with analysis.
This function can be used to do "printf debugging" on
compile-time executing code.
This function counts the number of least-significant (trailing in a big-Endian sense) zeroes in an integer.
If operand is a comptime-known integer,
the return type is comptime_int.
Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number
of bits that can represent the bit count of the integer type.
If operand is zero, @ctz returns
the bit width of integer type 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
For a function that returns a possible error code, use @import("std").math.divFloor.
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
For a function that returns a possible error code, use @import("std").math.divTrunc.
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.
path is absolute or relative to the current file, just like @import.
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.
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.
Converts an error value from one error set to another error set. Attempting to convert an error
which is not in the destination error set results in safety-protected Undefined Behavior.
This builtin can be called from a comptime block to conditionally export symbols.
When declaration is a function with the C calling convention and
options.linkage is Strong, this is equivalent to
the export keyword used on a function:
This function returns a pointer to the frame for a given function. This type
can be coerced to anyframe->T and
to anyframe, where T is the return type
of the function in scope.
This function does not mark a suspension point, but it does cause the function in scope
to become an async function.
This function returns the base pointer of the current stack frame.
The implications of this are target specific and not consistent across all
platforms. The frame address may not be available in release mode due to
aggressive optimizations.
This function is only valid within function scope.
Returns whether or not a struct, enum, or union has a declaration
matching name.
hasDecl.zig
const std = @import("std");const expect = std.testing.expect;const Foo = struct { nope: i32,pubvar blah = "xxx";const hi = 1;};test"@hasDecl" {try expect(@hasDecl(Foo, "blah"));// Even though `hi` is private, @hasDecl returns true because this test is// in the same file scope as Foo. It would return false if Foo was declared// in a different file.try expect(@hasDecl(Foo, "hi"));// @hasDecl is for declarations; not fields.try expect(!@hasDecl(Foo, "nope"));try expect(!@hasDecl(Foo, "nope1234"));}
Shell
$ zig test hasDecl.zig1/1 test "@hasDecl"... OKAll 1 tests passed.
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.
The following packages are always available:
@import("std") - Zig Standard Library
@import("builtin") - Target-specific information
The command zig build-exe --show-builtin outputs the source to stdout for reference.
@import("root") - Points to the root source file
This is usually `src/main.zig` but it depends on what file is chosen to be built.
Converts an integer to another integer while keeping the same numerical value.
Attempting to convert a number which is out of range of the destination type results in
safety-protected Undefined Behavior.
Converts an integer to a pointer. To convert the other way, use @ptrToInt. 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 Undefined Behavior.
Returns the maximum value of a and b. This builtin accepts integers, floats, and vectors of either. In the latter case, the operation is performed element wise.
NaNs are handled as follows: if one of the operands of a (pairwise) operation is NaN, the other operand is returned. If both operands are NaN, NaN is returned.
Returns the minimum value of a and b. This builtin accepts integers, floats, and vectors of either. In the latter case, the operation is performed element wise.
NaNs are handled as follows: if one of the operands of a (pairwise) operation is NaN, the other operand is returned. If both operands are NaN, NaN is returned.
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.
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.
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
For a function that returns an error code, see @import("std").math.mod.
Performs result.* = a * b. If overflow or underflow occurs,
stores the overflowed bits in result and returns true.
If no overflow or underflow occurs, returns false.
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.
Generally it is better to use @import("std").debug.panic.
However, @panic can be useful for 2 scenarios:
From library code, calling the programmer's panic function if they exposed one in the root source file.
When mixing C and Zig code, calling the canonical panic implementation across multiple .o files.
If operand is a comptime-known integer,
the return type is comptime_int.
Otherwise, the return type is an unsigned integer or vector of unsigned integers with the minimum number
of bits that can represent the bit count of the integer type.
This builtin tells the compiler to emit a prefetch instruction if supported by the
target CPU. If the target CPU does not support the requested prefetch instruction,
this builtin is a noop. This function has no effect on the behavior of the program,
only on the performance characteristics.
The 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.
The options argument is the following struct:
builtin.zig
/// This data structure is used by the Zig language code generation and/// therefore must be kept in sync with the compiler implementation.pubconst PrefetchOptions = struct {/// Whether the prefetch should prepare for a read or a write. rw: Rw = .read,/// 0 means no temporal locality. That is, the data can be immediately/// dropped from the cache after it is accessed.////// 3 means high temporal locality. That is, the data should be kept in/// the cache as it is likely to be accessed again soon. locality: u2 = 3,/// The cache that the prefetch should be preformed on. cache: Cache = .data,pubconst Rw = enum { read, write, };pubconst Cache = enum { instruction, data, };};
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
For a function that returns an error code, see @import("std").math.rem.
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.
Sets the floating point mode of the current scope. Possible values are:
test.zig
pubconst FloatMode = enum { Strict, Optimized,};
Strict (default) - Floating point operations follow strict IEEE compliance.
Optimized - Floating point operations may do all of the following:
Assume the arguments and result are not NaN. Optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined.
Assume the arguments and result are not +/-Inf. Optimizations are required to retain defined behavior over +/-Inf, but the value of the result is undefined.
Treat the sign of a zero argument or result as insignificant.
Use the reciprocal of an argument rather than perform division.
Perform floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-and-add).
Perform algebraically equivalent transformations that may change results in floating point (e.g. reassociate).
This is equivalent to -ffast-math in GCC.
The floating point mode is inherited by child scopes, and can be overridden in any scope.
You can set the floating point mode in a struct or module scope by using a comptime block.
Sets whether runtime safety checks are enabled for the scope that contains the function call.
test.zig
test"@setRuntimeSafety" {// The builtin applies to the scope that it is called in. So here, integer overflow// will not be caught in ReleaseFast and ReleaseSmall modes:// var x: u8 = 255;// x += 1; // undefined behavior in ReleaseFast/ReleaseSmall modes. {// However this block has safety enabled, so safety checks happen here,// 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 overflow// would not be caught in any build mode.@setRuntimeSafety(false);// var x: u8 = 255;// x += 1; // undefined behavior in all build modes. } }}
Shell
$ zig test test.zig -OReleaseFast1/1 test "@setRuntimeSafety"... thread 1443393 panic: integer overflowerror: the following test command crashed:docgen_tmp/zig-cache/o/4e8389a67cfac864bfee3c7c8a393602/test /home/andy/tmp/zig/build-release/zig
Note: it is planned to replace
@setRuntimeSafety with @optimizeFor
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.
The type of shift_amt is an unsigned integer with log2(T.bit_count) bits.
This is because shift_amt >= T.bit_count is undefined behavior.
Performs result.* = a << b. If overflow or underflow occurs,
stores the overflowed bits in result and returns true.
If no overflow or underflow occurs, returns false.
The type of shift_amt is an unsigned integer with log2(T.bit_count) bits.
This is because shift_amt >= T.bit_count is undefined behavior.
Constructs a new vector by selecting elements from a and
b based on mask.
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 from 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.
If a or b is undefined, it
is equivalent to a vector of all undefined with the same length as the other vector.
If both vectors are undefined, @shuffle returns
a vector with all elements undefined.
E must be an integer, float,
pointer, or bool. The mask may be any vector length, and its
length determines the result length.
vector_shuffle.zig
const std = @import("std");const Vector = std.meta.Vector;const expect = std.testing.expect;test"vector @shuffle" {const a: Vector(7, u8) = [_]u8{ 'o', 'l', 'h', 'e', 'r', 'z', 'w' };const b: Vector(4, u8) = [_]u8{ 'w', 'd', '!', 'x' };// To shuffle within a single vector, pass undefined as the second argument.// Notice that we can re-order, duplicate, or omit elements of the input vectorconst mask1: Vector(5, i32) = [_]i32{ 2, 3, 1, 1, 0 };const res1: Vector(5, u8) = @shuffle(u8, a, undefined, mask1);try expect(std.mem.eql(u8, &@as([5]u8, res1), "hello"));// Combining two vectorsconst mask2: Vector(6, i32) = [_]i32{ -1, 0, 4, 1, -2, -3 };const res2: Vector(6, u8) = @shuffle(u8, a, b, mask2);try expect(std.mem.eql(u8, &@as([6]u8, res2), "world!"));}
Shell
$ zig test vector_shuffle.zig1/1 test "vector @shuffle"... OKAll 1 tests passed.
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, this 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.
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.
Performs result.* = a - b. If overflow or underflow occurs,
stores the overflowed bits in result and returns true.
If no overflow or underflow occurs, returns false.
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:
Type information of structs, unions, enums, and
error sets has fields which are 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.
@TypeOf is a special builtin function that takes any (nonzero) 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:
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.
Zig has many instances of undefined behavior. If undefined behavior is
detected at compile-time, Zig emits a compile error and refuses to continue.
Most undefined behavior that cannot be detected at compile-time can be detected
at runtime. In these cases, Zig has safety checks. Safety checks can be disabled
on a per-block basis with @setRuntimeSafety. The ReleaseFast
and ReleaseSmall build modes disable all safety checks (except where overridden
by @setRuntimeSafety) in order to facilitate optimizations.
When a safety check fails, Zig crashes with a stack trace, like this:
test.zig
test"safety check" {unreachable;}
Shell
$ zig test test.zig1/1 test "safety check"... thread 1444643 panic: reached unreachable code/home/andy/tmp/zig/docgen_tmp/test.zig:2:5: 0x20785a in test "safety check" (test) unreachable;^/home/andy/tmp/zig/lib/std/special/test_runner.zig:80:28: 0x22f0c3 in std.special.main (test) } else test_fn.func();^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x22843c in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x20907e in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x208116 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x207f22 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^error: the following test command crashed:docgen_tmp/zig-cache/o/e62d5b643d08f1acbb1386db92eb0f23/test /home/andy/tmp/zig/build-release/zig
$ zig test test.zig./docgen_tmp/test.zig:5:14: error: reached unreachable code if (!ok) unreachable; // assertion failure^./docgen_tmp/test.zig:2:11: note: called from here assert(false);^./docgen_tmp/test.zig:1:10: note: called from herecomptime {^
These functions provided by the standard library return possible errors.
@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
Example of catching an overflow for addition:
test.zig
const math = @import("std").math;const print = @import("std").debug.print;pubfnmain() !void {var byte: u8 = 255; byte = if (math.add(u8, byte, 1)) |result| result else |err| { print("unable to add one: {s}\n", .{@errorName(err)});return err; }; print("result: {}\n", .{byte});}
Shell
$ zig build-exe test.zig$ ./testunable to add one: Overflowerror: Overflow/home/andy/tmp/zig/lib/std/math.zig:463:5: 0x23447b in std.math.add (test) return if (@addWithOverflow(T, a, b, &answer)) error.Overflow else answer;^/home/andy/tmp/zig/docgen_tmp/test.zig:8:9: 0x22d0c4 in main (test) return err;^
const Foo = enum { a, b, c,};comptime {const a: u2 = 3;const b = @intToEnum(Foo, a); _ = b;}
Shell
$ zig test test.zig./docgen_tmp/test.zig:8:15: error: enum 'Foo' has no tag matching integer value 3 const b = @intToEnum(Foo, a);^./docgen_tmp/test.zig:1:13: note: 'Foo' declared hereconst Foo = enum {^
At runtime:
test.zig
const std = @import("std");const Foo = enum { a, b, c,};pubfnmain() void {var a: u2 = 3;var b = @intToEnum(Foo, a); std.debug.print("value: {s}\n", .{@tagName(b)});}
Shell
$ zig build-exe test.zig$ ./testthread 1447823 panic: invalid enum value/home/andy/tmp/zig/docgen_tmp/test.zig:11:13: 0x22cdd9 in main (test) var b = @intToEnum(Foo, a);^/home/andy/tmp/zig/lib/std/start.zig:551:22: 0x2264bc in std.start.callMain (test) root.main();^/home/andy/tmp/zig/lib/std/start.zig:495:12: 0x2070de in std.start.callMainWithArgs (test) return @call(.{ .modifier = .always_inline }, callMain, .{});^/home/andy/tmp/zig/lib/std/start.zig:409:17: 0x206176 in std.start.posixCallMainAndExit (test) std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));^/home/andy/tmp/zig/lib/std/start.zig:322:5: 0x205f82 in std.start._start (test) @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});^(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.
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:
$ zig test allocator.zig1/1 test "using an allocator"... OKAll 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 do perform basic leak detection.
Zig has a general purpose allocator available to be imported
with std.heap.GeneralPurposeAllocator. However, it is still recommended to
follow the Choosing an Allocator guide.
What allocator to use depends on a number of factors. Here is a flow chart to help you decide:
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.
Are you linking libc? In this case, std.heap.c_allocator is likely
the right choice, at least for your main allocator.
Is the maximum number of bytes that you will need bounded by a number known at
comptime? In this case, use std.heap.FixedBufferAllocator or
std.heap.ThreadSafeFixedBufferAllocator depending on whether you need
thread-safety or not.
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
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().
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.
Are you writing a test, and you want to make sure error.OutOfMemory
is handled correctly? In this case, use std.testing.FailingAllocator.
Are you writing a test? In this case, use std.testing.allocator.
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 comptimestruct 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.
String literals such as "foo" 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:
$ zig test strlit.zig1/1 test "string literal to constant slice"... OKAll 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 Undefined Behavior.
var declarations at the top level or in struct declarations are stored in the global
data section.
The location of memory allocated with allocator.alloc or
allocator.create is determined by the allocator's implementation.
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:
Only some operating systems have an overcommit feature.
Linux has it enabled by default, but it is configurable.
Windows does not overcommit.
Embedded systems do not have overcommit.
Hobby operating systems may or may not have overcommit.
For real-time systems, not only is there no overcommit, but typically the maximum amount
of memory per application is determined ahead of time.
When writing a library, one of the main goals is code reuse. By making code handle
allocation failure correctly, a library becomes eligible to be reused in
more contexts.
Although some software has grown to depend on overcommit being enabled, its existence
is the source of countless user experience disasters. When a system with overcommit enabled,
such as Linux on default settings, comes close to memory exhaustion, the system locks up
and becomes unusable. At this point, the OOM Killer selects an application to kill
based on heuristics. This non-deterministic decision often results in an important process
being killed, and often fails to return the system back to working order.
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 Undefined Behavior occur).
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.
The Zig Build System provides a cross-platform, dependency-free way to declare
the logic required to build a project. With this system, the logic to build
a project is written in a build.zig file, using the Zig Build System API to
declare and configure build artifacts and other tasks.
Some examples of tasks the build system can help with:
Creating build artifacts by executing the Zig compiler. This includes
building Zig source code as well as C and C++ source code.
Capturing user-configured options and using those options to configure
the build.
Surfacing build configuration as comptime values by providing a
file that can be imported by Zig code.
Caching build artifacts to avoid unnecessarily repeating steps.
Executing build artifacts or system-installed tools.
Running tests and verifying the output of executing a build artifact matches
the expected value.
Running zig fmt on a codebase or a subset of it.
Custom tasks.
To use the build system, run zig build --help
to see a command-line usage help menu. This will include project-specific
options that were declared in the build.zig script.
This build.zig file is automatically generated
by zig init-exe.
build.zig
const Builder = @import("std").build.Builder;pubfnbuild(b: *Builder) void {// Standard target options allows the person running `zig build` to choose// what target to build for. Here we do not override the defaults, which// means any target is allowed, and the default is native. Other options// for restricting supported target set are available.const target = b.standardTargetOptions(.{});// Standard release options allow the person running `zig build` to select// between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall.const mode = b.standardReleaseOptions();const exe = b.addExecutable("example", "src/main.zig"); exe.setTarget(target); exe.setBuildMode(mode); exe.install();const run_cmd = exe.run(); run_cmd.step.dependOn(b.getInstallStep());if (b.args) |args| { run_cmd.addArgs(args); }const run_step = b.step("run", "Run the app"); run_step.dependOn(&run_cmd.step);}
Although Zig is independent of C, and, unlike most other languages, does not depend on libc,
Zig acknowledges the importance of interacting with existing C code.
There are a few ways that Zig facilitates C interop.
The @cImport builtin function can be used
to directly import symbols from .h files:
test.zig
const c = @cImport({// See https://github.com/ziglang/zig/issues/515@cDefine("_NO_CRT_STDIO_INLINE", "1");@cInclude("stdio.h");});pubfnmain() void { _ = c.printf("hello\n");}
Shell
$ zig build-exe test.zig -lc$ ./testhello
The @cImport function takes an expression as a parameter.
This expression is evaluated at compile-time and is used to control
preprocessor directives and include multiple .h files:
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.
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.
@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.
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.zig
const c = @cImport({@cDefine("_NO_CRT_STDIO_INLINE", "1");@cInclude("stdio.h");});pubfnmain() void { _ = c;}
Shell
$ zig build-exe verbose.zig -lc --verbose-cimportinfo(compilation): C import source: docgen_tmp/zig-cache/o/1f1ad63cdccaad2058225bdcce43845b/cimport.hinfo(compilation): C import .d file: docgen_tmp/zig-cache/o/1f1ad63cdccaad2058225bdcce43845b/cimport.h.dinfo(compilation): C import output: docgen_tmp/zig-cache/o/7e416bb14bf9f4fbade20fc44c3c185e/cimport.zig$ ./verbose
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.
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.
C Translation makes a best-effort attempt to translate function-like macros into equivalent
Zig functions. Since C macros operate at the level of lexical tokens, not all C macros
can be translated to Zig. Macros that cannot be translated will be be demoted to
@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.
Consider the following example:
macro.c
#define MAKELOCAL(NAME, INIT) int NAME = INITint foo(void) { MAKELOCAL(a, 1); MAKELOCAL(b, 2); return a + b;}
Shell
$ zig translate-c macro.c > macro.zig
macro.zig
pubexportfnfoo() c_int {var a: c_int = 1;var b: c_int = 2;return a + b;}pubconst MAKELOCAL = @compileError("unable to translate C expr: unexpected token .Equal"); // macro.c:1:9
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.
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.
Coerces to other pointer types, as well as Optional Pointers.
When a C pointer is coerced to a non-optional pointer, safety-checked
Undefined Behavior occurs if the address is 0.
Allows address 0. On non-freestanding targets, dereferencing address 0 is safety-checked
Undefined 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.
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 to the struct's fields or member data. That syntax looks like
this:
ptr_to_struct.*.struct_member
This is comparable to doing -> in C.
When a C pointer is pointing to an array of structs, the syntax reverts to this:
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:
// This header is generated by zig from mathtest.zig#include "mathtest.h"#include <stdio.h>int main(int argc, char **argv) { int32_t result = add(42, 1337); printf("%d\n", result); return 0;}
For host environments like the web browser and nodejs, build as a dynamic library using the freestanding
OS target. Here's an example of running Zig code compiled to WebAssembly with nodejs.
Zig's support for WebAssembly System Interface (WASI) is under active development.
Example of using the standard library and reading command line arguments:
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.PreopenList:
The Zig Standard Library (@import("std")) has architecture, environment, and operating system
abstractions, and thus takes additional work to support more platforms.
Not all standard library code requires operating system abstractions, however,
so things such as generic data structures work on all above platforms.
The current list of targets supported by the Zig Standard Library is:
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.
Roughly speaking: camelCaseFunctionName, TitleCaseTypeName,
snake_case_variable_name. More precisely:
If x is a type
then x should be TitleCase, unless it
is a struct with 0 fields and is never meant to be instantiated,
in which case it is considered to be a "namespace" and uses snake_case.
If x is callable, and x's return type is
type, then x should be TitleCase.
If x is otherwise callable, then x should
be camelCase.
Otherwise, x should be snake_case.
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.
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.
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.
Note that running zig fmt on a source file will implement all recommendations mentioned here.
Note also that the stage1 compiler does not yet support CR or HT control characters.
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.
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.
Function parameters and struct fields can be declared with anytype in place of the type.
The type will be inferred where the function is called or the struct is instantiated.
await can be used to suspend the current function until the frame provided after the await completes.
await copies the value returned from the target function's frame to the caller.
catch can be used to evaluate an expression if the expression before it evaluates to an error.
The expression after the catch can optionally capture the error value.
comptime before a declaration can be used to label variables or function parameters as known at compile time.
It can also be used to guarantee an expression is run at compile time.
extern can be used to declare a function or variable that will be resolved at link time, when linking statically
or at runtime, when linking dynamically.
An if expression can test boolean expressions, optional values, or error unions.
For optional values or error unions, the if expression can capture the unwrapped value.
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.
The nosuspend keyword can be used in front of a block, statement or expression, to mark a scope where no suspension points are reached.
In particular, inside a nosuspend scope:
Using the suspend keyword results in a compile error.
Using await on a function frame which hasn't completed yet results in safety-checked Undefined Behavior.
Calling an async function may result in safety-checked Undefined Behavior, because it's equivalent to await async some_async_fn(), which contains an await.
Code inside a nosuspend scope does not cause the enclosing function to become an async function.
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 allow the function access to its frame before control flow returns to the call site.
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.
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.
Emits a panic in Debug and ReleaseSafe mode, or when using zig test.
Does not emit a panic in ReleaseFast mode, unless zig test is being used.
usingnamespace is a top-level declaration that imports all the public declarations of the operand,
which must be a struct, union, or enum, into the current scope.
volatile can be used to denote loads or stores of a pointer have side effects.
It can also modify an inline assembly expression to denote it has side effects.
A while expression can be used to repeatedly test a boolean, optional, or error union expression,
and cease looping when that expression evaluates to false, null, or an error, respectively.