Is custom allocators the right abstraction?

libs
6

(drive by commend by someone who is touching allocators from a distance)

I think the most powerful API for allocator would be to pass it in at the call-site, similar to how OnceCell is more powerful than Lazy, and how hashbrown's raw_entry API is more powerful than K: Hash+Eq API (we really need a name for this pattern/idea... (provisional name: Call Site Dependency Injection)).

That is, the API like

impl Vec<T, A> {
    fn alloc_push(&mut self, alloc: &mut A, elem: T) -> Result<T, A::Err>;
}

This will allow, for example, to use the same non-zst allocator for the bunch of different Vecs, without storing a redundant pointer in every Vec.

An interesting case study here would be Zig. It's standard library provides, eg, Vec in two flavors: one stores allocator as a field, another needs an allocator argument for each method call:

7 Likes