> the common case is small values with periodic very large values

I find that a common scenario here is parsers where "Real world" input will tend to be small but you're also exposed to adversarial input. e.g. a parser for function prototypes would typically not expect to see more than 16 arguments in the wild, but you still need to handle it without erroring in case someone decides to send a 1000-argument function through your parser.

That would get you almost none of the benefits of arenas and other types of allocators. Recommend https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...

You can use regular buffers for many things, but a lot of core Zig std functions require an allocator (satisfying std.mem.Allocator interface) as an argument. This means the developer retains control of how memory is managed. It's also advantageous for testing, as you can pass in specialized allocator for detecting memory leaks during testing but use the more efficient allocator for release mode. You can wrap regular buffer into a FixedBufferAllocator which just uses stack values. ArenaAllocator is just a container that wraps an underlying allocator but it will free everything when you call defer arena.deinit(), which is useful for short-lived things like http requests.

Doing that seems like it's just manually replicating a call stack (with potential for error); I don't see what the benefit is. Making functions independent of global state - and allocation is a huge source of implicit dependency on global state - is generally considered good programming practice.