English for Zig Developers

Zig’s design philosophy — no hidden control flow, no hidden allocations — comes with a vocabulary that’s precise about what happens at compile time versus runtime, and who owns which piece of memory. Getting this language right matters especially in code review, where a vague description of an allocator or an error union can hide a real bug. This guide covers the English used when discussing Zig code with a team.

Key Vocabulary

Comptime — code or values evaluated at compile time rather than runtime, used for generics, constant folding, and metaprogramming. “We can compute the lookup table at comptime instead of building it on every program start.”

Error union — a type like !T representing either a successful value of type T or an error, forcing the caller to handle both cases explicitly. “The function returns an error union, so the caller has to either handle the error or propagate it with try.”

Allocator — an explicit object passed into functions that need to allocate memory, making memory ownership visible in the function signature rather than implicit. “Pass in the arena allocator here instead of the general-purpose one — we don’t need to free these individually.”

Defer — a statement that schedules code to run when the current scope exits, commonly used to guarantee cleanup like freeing memory. “Add a defer allocator.free(buffer) right after the allocation so we don’t leak memory on the early-return path.”

Sentinel-terminated slice — a slice type where a known value (like a null byte) marks the end, commonly used for C-string interop. “We need a sentinel-terminated slice here because this function is calling into a C library that expects a null-terminated string.”

Undefined behavior (in Zig) — behavior that Zig’s safety checks catch in debug builds (like out-of-bounds access) but that becomes unchecked in optimized release builds. “That crash only appeared in the release build because it’s undefined behavior that the debug build’s safety checks would have caught.”

Common Phrases

• “Which allocator is this function using — is it the caller’s responsibility to free the result?”
• “This should be a comptime parameter, not a runtime one, since it never changes after compilation.”
• “Did we forget a defer here? This path allocates but I don’t see a matching free.”
• “The error union needs a catch or try — the compiler won’t let this compile silently.”
• “Is this safe in a release-fast build, or does it depend on debug-mode safety checks?”

Example Sentences

Reviewing a pull request: “This function allocates with the general-purpose allocator but never frees on the error path — can we add a defer right after the allocation to cover both the success and error cases?”

Explaining a design decision: “We pushed the allocator down as a parameter instead of using a global one, so callers can choose an arena allocator for short-lived requests and avoid per-object frees entirely.”

Describing a bug: “The out-of-bounds read only showed up in the optimized build because it’s undefined behavior — the debug build’s bounds checking would have caught it immediately.”

Professional Tips

• Say “comptime” as its own word, not “compile-time,” when referring to Zig’s specific mechanism — it signals you mean the language feature, not the general concept.
• When reviewing allocation code, always ask “who owns this, and who frees it?” — Zig makes ownership explicit, so the answer should be a specific allocator, not “whoever needs it.”
• Distinguish debug-mode safety checks from release-mode behavior when explaining why a bug appeared only in production.
• Use “error union” rather than “exception” — Zig has no exceptions, and using exception terminology confuses newcomers about the control flow.

Practice Exercise

1. Explain in two sentences why passing an explicit allocator is different from a language with automatic garbage collection.
2. Write a one-sentence code review comment flagging a missing defer on an allocation.
3. Describe, in your own words, the difference between a bug caught by debug-mode safety checks and undefined behavior in a release build.