Embracing Unmanaged, plans with eg. AutoHashMap?

netvor · September 8, 2025, 9:47am

In 0.14.0 notes, a plan has been explained to converge towards unmanaged variants of containers. Other than the ubiquitous ArrayList, ArrayHashMap has also been mentioned. IIUC the reasoning applies basically to all structures, though.

As promised, in 0.15.1, the ArrayListUnmanaged has already been renamed to ArrayList and the managed variant is now deprecated. But the situation is not so clear for some other structures, such as eg. AutoHashMap or ArrayHashMap. At least not by looking for specific structures mentioned or by looking for “deprecated” in docstring … but these don’t have docstrings, so…

As I’m moving my codebase to 0.15.1, I’m trying to use the opportunity to make it more future proof and “Zigalicious”, so I’m on a look out for APIs that are deprecated or planned deprecated. Would it be safe to assume that everything is eventually going to go in that direction?

Or is there more nuance and I would be better to wait for a more clear “official” plan? (I’m aware of Zig’s priorities; I don’t want to sound impatient…)

rpkak · September 8, 2025, 9:51am

See

github.com/ziglang/zig

std.ArrayHashMap: add `reinit` method and other housekeeping, including the move towards "unmanaged" containers

master ← std.ArrayHashMap

opened 10:27PM - 27 Nov 24 UTC

andrewrk

+88 -74

`std.ArrayHashMap` is now deprecated and aliased to `std.ArrayHashMapWithAllocat…or`. To upgrade, switch to `ArrayHashMapUnmanaged` which will entail updating callsites to pass an allocator to methods that need one. After Zig 0.14.0 is released, `std.ArrayHashMapWithAllocator` will be removed and `std.ArrayHashMapUnmanaged` will be a deprecated alias of `ArrayHashMap`. After Zig 0.15.0 is released, the deprecated alias `ArrayHashMapUnmanaged` will be removed. This move comes from unanimous agreement among veteran Zig users who have converged on the "unmanaged" container variants. They act as better building blocks, avoiding storing the same data redundantly, and the presence/absence of the allocator parameter dovetails nicely with the reserve capacity / reserved insertion pattern.

(edit: liked wrong PR first)

and

github.com/ziglang/zig

MemoryPool: Add unmanaged versions

master ← Justus2308:master

opened 03:40PM - 13 Mar 25 UTC

Justus2308

+281 -113

The memory pool takes a special place among the Zig std allocators since it is t…he only one that doesn't expose an `Allocator` interface. Because it doesn't have to adhere to the `Allocator` interface (which doesn't take an explicit child allocator) the memory pool is free to take an allocator as a parameter for its functions and it makes sense to me that there should be an unmanaged version. This is also in accordance with Zig's stated goal to [embrace unmanaged-style containers](https://ziglang.org/download/0.14.0/release-notes.html#Embracing-Unmanaged-Style-Containers) by 0.15.0. This pull request adds `MemoryPoolUnmanaged`, `MemoryPoolAlignedUnmanaged`, `MemoryPoolExtraUnmanaged` and the corresponding `...WithAllocator` variants, to which the old types now alias. `MemoryPoolError` has also been replaced with `Allocator.Error` since it's the same anyways.