Why Zig Has No Hidden Allocations

In Zig, no standard library function quietly grabs heap memory. If code needs to allocate, it must say so out loud. 📦

Anything that allocates takes an allocator as a parameter. Memory cannot appear unless you hand a function the tool to make it.

Zig has no new operator and no garbage collector. Nothing reaches into the heap behind your back the way many languages do.

Because allocation is visible, you always know where memory comes from. That is vital for embedded chips, kernels, and tight game loops.

A function that may allocate shows it in its signature: it takes an allocator and usually returns an error union with !.

Plain locals live on the stack and need no allocator. You only reach for one when a value must outlive its function or grow at run time.

Asking for heap memory can fail, so allocating functions return an error. You must handle a possible OutOfMemory, never ignore it.

Whoever calls the allocator owns the result and must free it. Zig never frees your memory for you, so ownership is always clear.

Because the allocator is a parameter, you can swap strategies without changing logic. Tests use one allocator, production another.

A well-written library never hides an allocation. It accepts your allocator, so you control memory even inside other people is code.

This rule is part of Zig is promise of no hidden control flow. Explicit allocation keeps programs predictable and easy to reason about. ✅

Recall how a Zig function gets the power to allocate.

You saw that Zig has no hidden allocations: memory comes only through an allocator you pass in, and you own and free whatever you make. 🎯