# Short(ish) rant on the current `Allocator` trait/API

So, the thing I *actually* think is the biggest issue (or at least the reason IMO we *really* can't stabilize the current API as it is) is that dynamic dispatch -- `dyn Allocator` -- feels like a complete afterthought and has serious problems (and even if you don't expect to use it (as I didn't), it actually is hard to avoid (unless you intend to fall back to the global allocator in a *lot* of the code))

Concretely: The current design intends to support writing code which is generic over the allocator via type params, e.g. `Vec<T, A>`. This seemed good to me at first, but really sucked when I tried to use it heavily in my game engine.

1. For one, pretty much everything allocates and returns allocated data, so a staggering number of functions need to be generic over the allocator now.

This causes all of them to be monomorphised as many times as you have allocators, which is... bad for code size, and compile times (but maybe this is fixable or doesn't matter that much).

2. A bigger issue is that many things *can't* be generic over the allocator. For example, object-safe traits.

It's hopefully clearly unreasonable to ask all trait methods that would need an allocator to return allocated types (or even allocate internally) to have a `<A: Allocator>` type param.

3. Thankfully `Allocator` is object safe, and even better, for most allocators, there's actually very little is gained from having the static type, For example, in `Vec<T, A>`, it's just a call to `malloc` or similar either way.

At this point, it's enough motivation for me to try using dynamic dispatch. This may mean that stuff like `bumpalo` is meaningfully slower, but the hope is that there's a way to make this work that still allows static dispatch.

4. Unfortunately, initially I tried passing around `&dyn Allocator` -- `Allocator::by_ref` encourages this, perhaps. So, I do a transform like this:

- Trait method I'd like to write, but can't because generic param breaks object safety:

    fn foo<A: Allocator>(&self, a; A) -> Vec<T, A>`

- Object safe version:

    fn foo<'a>(&self, a: &'a dyn Allocator) -> Vec<T, &'a dyn Allocator>

Sadly, there’s no way to go from `&'alloc dyn Allocator` back to an owned allocator, so I don't see a way to get out of the `Vec<T, &'a dyn Allocator>`, even if the callsite looked like `thing.foo(&a)`.

Maybe that could be fixed though, but either way this is mostly annoying rather than broken. You just have to accept your codebase becoming like `rustc`s, where nothing is an owned type ever again

(Err, as far as I can tell, 99% of the structs and functions in rustc are parameterized over `'tcx`, so in theory I could do that, but for `'alloc`. In practice I'm not sure I'm good enough at lifetimes for this, but who knows).

5. So, probably a a better approach is a smart pointer type. So lets say we don't care about thread safety (since non-Send/Sync allocators are a major use case for non-global allocators, and this kind of thing is the whole point of the type param anyway). So we're considering stuff like `Rc<dyn Allocator>` for now.

This seems good... until you try to create one, at which point you realize that it's really `Rc<dyn Allocator, ???>`. That is, you need to figure out what allocator to use to allocate the allocator trait object.

And definitely it's viable to just use the global allocator for this, but it is pretty annoying...

... Especially because in the majority of cases, you shouldn't even *need* to allocate anything for this, since it's a ZST anyway. And for that matter, for these you shouldn't need to maintain a refcount)...

6. For completeness, there's also `Vec<T, &'static dyn Allocator>`. This works, but is either dangerous or unflexible.

FWIW, this *is* what I used the most, although that code was often unsound and wildly dangerous. (Not to mention, IMO it seems not super great appropriate if it is the painful path in standard allocator API)

In my game engine I did make an honest go of this, and did use all of them in different places (much of it was for integration with my (older) C++ game engine).

What I've learned since then is that the problem in 5 is actually already basically solved by `RawWaker`/`RawWakerVTable` in `std::task`, which emulate trait object functionality without needing an allocator.

While there are a bunch of things about wakers that are super different for allocators, and I *don't* actually think the `RawWaker` API is very close to what we'll end up with at all. But it does solve many of the issues (and brings its own), so I think it its worth really considering as either a starting point, or something.

But yeah, either way, my personal takeaway from trying to earnestly use the allocator API (in essentially its current shape), is that it needs major rework, for the reasons above (esp. 1-3).