Convention: allocators

[thorny smelt]

Quick question about convention:
With the 0.15.0 change for ArrayList to not keep its allocator as a field, is it a good idea to modify my code such that allocators are always provided? Are there any dangers to doing this?

[sterile echo]

usually you'd want every function that does allocations to take in a std.mem.Allocator argument; this has a few benefits, such as making allocation points obvious, and reducing the amount of std.mem.Allocator stored in the program

[thorny smelt]

what I did before was store *std.mem.Allocator and dereference every time I needed it

the idea of passing it everytime is a little annoying but I get the idea behind it

[sterile echo]

*std.mem.Allocator is a very odd type to encounter! it has some uses, but it's very rare to see.
as I wrote, just passing around allocators (the std.mem.Allocator values themselves! not pointers to them!) is the preferred approach

[thorny smelt]

anyway the context of all of this was that I was implementing a forth in zig (I had 0.14.0 as zls wasn't updated to 0.15.0 yet), and when updating zig and zls everything broke

which meant I had to fix everything

and that gave me the idea of removing the allocator field

[stiff harbor]

Passing the allocator explicitly is usually preferred, but in the end it's up to you to decide, even zig does not always follow this new "convention".
https://ziglang.org/documentation/master/std/#std.zig.Parse

In the above case probably because it would be very annoying in recursive function calls.

[thorny smelt]

[vernal moon]

the key insight here is that Parse is basically a singleton

it's inited inside the parse function, and deinited at the end, meaning there's really only ever a single one

the main point of unmanaged datastructures is to avoid storing multiple copies of the same allocator, which wastes memory and makes it harder to tell what allocator is being used where

[sterile echo]

passing std.mem.Allocators as function arguments means you also never accidentally leak an allocator past its implementation's lifetime

[vernal moon]

mhm

the only real thing u lose out on by doing the "put the allocator on a local singleton that only exists for the duration of a function" thing that std.zig.Parse does is the explicitness - it's harder to see what functions allocate