At the moment, Rust's
alloc crates assume the existence of a single global allocator, and that it's impossible to run out of memory. These are great assumptions for user-land processes, but, in principle, perfectly robust and perfectly re-usable library would love to opt-out of those.
My understanding is that "perfect" libraries, which do not want to bake this assumption in, would like to either accept a caller-provided allocation, or an allocator. Zig's APIs are a great example here --- every function that can allocate has an
a: &Allocator parameter.
However, I actually haven't seen libraries, parameterized by the alloctor, in the wild. Libs like
fontdue look like they could, in theory, expose an API which use caller-provided allocator, but they are written under the
alloc assumption anyway.
Why is this the case? Is it because no one actually needs this additional flexibility? Or is it because Rust type-system makes makes expressing this pattern significantly more awkward than just using a global allocator?