We used to have a version of ArrayList that bundled an allocator in the stdlib, we removed it because our experience having written Zig code for a few years led us to reach for the allocator-less variant almost always.

One aspect your argument is missing is that if you are juggling many ArrayLists, having each bundle its own copy of the allocator (instead of storing it just once) means wasting 16 bytes per ArrayList. The allocator-less variant is simply more flexible in that regard.

ArrayLists used to store an allocator at init time and then use it for appends and whatnot afterwards. It was decided that this hid allocations and wasn't appropriate for the standard library.

It is of course trivial to define your own arraylist type that wraps an allocator on initialisation if you so wish.

That's because in Zig that would be seen as a surprise side effect - the allocator is expected when the action is performed, not when it's "prepared", this way you know append() allocates. Otherwise it wouldn't be explicit which Array methods allocated.

The Odin way is useful, too. Depends on what you're building.

That's just a matter of wrapping the allocator if you feel fhat is better approach. Question is, should there always be an allocator around with arr or do you want to split a build phase from an immutable use phase.

[dead]