std.ArrayList: make unmanaged the default

[andrewrk]

As a nice little bonus, the namespaces no longer have any redundancies.

Upgrade Guide

• std.ArrayList -> std.array_list.Managed
  • warning: will be eventually removed from standard library
• std.ArrayListAligned -> std.array_list.AlignedManaged
  • warning: will be eventually removed from standard library

[mlugg]

Suggested change

	/// slice of `T` values. Initialize with `init`.
	/// slice of `T` values.

nothing else needed as the lines below say how you should actually inititalize

[AndrewKraevskii]

Also init just doesn't exist on ArrayList

[mlugg]

yes, that's why i made this suggestion?

[AndrewKraevskii]

Since its breaking change wouldn't it also make sense to remove default field values?

[andrewrk]

Tested locally with stage3/bin/zig build test -Dskip-release -Dskip-non-native

[MahdiGMK]

why are we removing managed containers? what pattern do unmanaged containers allow that managed ones dont?

[andrewrk]

It's the other way around. Having an extra field is more complicated than not having an extra field, so not having it is the null hypothesis. What pattern does having an allocator field allow that not having one doesn't?

• avoiding accidentally using the wrong allocator
• convenience when you need to pass an allocator also

But there are downsides:

• worse method function signatures in the face of reservations
• lost inability to statically initialize
• extra memory storage cost, particularly for nested containers

The reasoning goes like this: the upsides are not worth the downsides. Also, given that the correct allocator is always handy, and incorrect use can be trivially safety-checked, the simplicity of only having one implementation is quite valuable compared to the convenience that is gained by having a second implementation.

In practice, this has not been a controversial change with experienced Zig users.

[Fincap]

Are there any plans on changing the other std containers to fit this new pattern?

• std.ArrayList -> std.array_list.Managed
• std.ArrayListAligned -> std.array_list.AlignedManaged
• std.HashMap -> std.hash_map.Managed
• std.AutoHashMap -> std.hash_map.AutoManaged
• std.StringHashMap -> std.hash_map.StringManaged
• std.ArrayHashMap -> std.array_hash_map.Managed
• std.AutoArrayHashMap -> std.std_array_hash_map.AutoManaged
• std.StringArrayHashMap -> std.std_array_hash_map.StringManaged
• std.DynamicBitSet -> std.bit_set.DynamicManaged

Apologies in advance if this has been answered in another PR/issue, my searches have turned up nothing. I can move this into its own issue if this would be more appropriately placed there.

[andrewrk]

Yes, all of them.

[margual56]

Hi all - I just tried out version 0.15.1 and wanted to share some late feedback on this change.

As was mentioned in the discussion:

this has not been a controversial change with experienced Zig users

That may be true, but from my perspective, this shift pushes complexity onto the user, particularly newer users. The allocator is now required in every single call to ArrayList et al. (e.g., init, deinit, append, etc.), which increases verbosity and makes common patterns more cumbersome. While the complexity hasn't been removed, it's essentially been offloaded from the API to the user, which raises the barrier to entry in an area that’s quite central to Zig development.

Don't think just about having a self-contained ArrayList inside a function - imagine passing an ArrayList between modules, while also needing to keep track of the allocator reference. In practice, users might end up writing their own wrapper around ArrayList just for convenience. At that point, why remove it from std in the first place?

Maybe passing ArrayLists around is considered an anti-pattern in Zig. If so, it would help to make that guidance more explicit.

I understand the rationale behind the decision, but I still think this change deserves more scrutiny given how fundamental these structs are.

[MahdiGMK]

Don't think just about having a self-contained ArrayList inside a function - imagine passing an ArrayList between modules, while also needing to keep track of the allocator reference. In practice, users might end up writing their own wrapper around ArrayList just for convenience. At that point, why remove it from std in the first place?

Maybe passing ArrayLists around is considered an anti-pattern in Zig. If so, it would help to make that guidance more explicit.

actually in that case, you are already passing an allocator (and if you dont, you probably should anyways so you could see "The Allocator" and the possibility of memory allocation) so there would be no api update pretty much

and also passing ArrayList around should only be only limited to functions that may modify the ArrayList in "ArrayList ways", otherwise you'd be better of passing []T s around.
It looks nicer, It feels and performs better and its more flexible