Rust developers question Allocator::by_ref as stabilization nears

A tiny method on Rust’s allocator trait has become the latest signal that memory-management ergonomics are still being tuned before stabilization. On May 26, a Rust Internals thread asked what Allocator::by_ref is for after spotting it in the allocator API, and the confusion landed in a part of the language where every extra move, borrow, or wrapper can matter.

The reason the question matters is baked into the trait itself. The Rust standard library says Allocator can allocate, grow, shrink, and deallocate arbitrary blocks of data described by Layout, and that it is designed to be implemented on zero-sized types, references, or smart pointers. It also allows zero-sized allocations, which separates it from GlobalAlloc and makes it clear this is not just a thin alias for the old global-memory story. In practice, that means by_ref is not necessarily a cosmetic borrow. In an API built to accept owned values, references, and pointer-like wrappers, it can serve as an adapter that turns a concrete allocator into a borrowed view that generic code can carry along.

That is the part likely to matter most to people writing allocator-aware libraries. If an API wants some allocator-shaped thing without taking ownership of the allocator itself, by_ref can let the same allocator participate in iterator-style or combinator-style chains without being moved. That is especially useful in generic libraries and embedded code, where lifetimes are tight and unnecessary cloning or moving can be awkward, expensive, or both. The confusion around the method is useful precisely because it exposes the edge where a borrow stops being obvious and starts acting like a design tool.

The broader backdrop is older than this one thread. RFC 1974, global allocators, aimed to overhaul Rust’s global allocator APIs and put them on a path to stabilization, while the current Allocator API remains a nightly-only experimental feature behind tracking issue #32838. Rust’s standard docs still distinguish the global allocator used by Box<T> and Vec<T> from allocator-per-collection models, which explains why this space keeps drawing design questions even after years of discussion.

That long-running debate has also centered on container pointer overhead and on use cases that a plain allocator trait does not cover cleanly, including inline allocation raised in a 2023 pre-RFC Storage API discussion. So by_ref is doing more than adding one more helper method. It is testing how much of Rust’s allocator story can feel natural to the people who will actually touch it: custom container authors, embedded developers, and library maintainers trying to thread an allocator through an API without making ownership the whole story.