Repository navigation
Roadmap #48
Description
Activity
- pinned this issue
on Mar 12, 2020 Updated OP.
@TimDiekmann what are next steps? Are we waiting for potential feedback from users on our changes to the API before we proceed?
I'm currently testing the API with
alloc-compose. I also testing out, on how well taking&selfis working. While most allocators could use&selfinstead of&mut selfthis has a major downside:Cellis!Sync, so using internal mutability forSyncallocators have to use atomics or other structs, which introduce more overhead. For the same reason,Bumpfrom bumpalo is also!Sync.Reacted by Wodann- deprecate
GlobalAlloc
Actively emitting deprecation warnings causes churn. What benefit does this bring in exchange?
- add
#[doc(hidden)]toGlobalAlloc
GlobalAllocis stable, so there will always be legacy code that uses it (even if with deprecating warnings). Hiding its docs would be confusing to future readers of such code, for what benefit? Compared to documenting that usingAllocRefinstead is preferred.Reacted by Kornel- deprecate
Isn't that the point of deprecation warnings?
Error::sourcewas introduced in 1.30,Error::causewas deprecated in 1.33. I expect many more people to use theErrortrait than theGlobalAlloctrait. Sure, we could also just leaveGlobalAllocalone 🙂Hiding its docs would be confusing to future readers of such code
Fair point.
@TimDiekmann Could you update the roadmap with recent changes and what's left for us to do?
Also, can we proceed with #7 now that unstable generic trait instantiations are supported?
Updated the roadmap.
Also, can we proceed with #7 now that unstable generic trait instantiations are supported?
rust-lang/rust#72314 is not merged yet as @varkor asked for a few more tests. I will open a new issue for each collection when it's merged.
Reacted by Wodann and Gurwinder SinghThanks for cleaning up the roadmap and outstanding issues 👍
Should
AllocRefbe renamedAllocatornow or it's a different AllocRef?Reacted by Gurwinder Singh and Wodann- Reacted by Gurwinder Singh and Wodann
Hey I see that the last message in this issue is 3yo, what's the current status? Is there any way to get involved and help move the needle a bit?
Reacted by Pavel Atanasov, Marijan Smetko, ghosti3, Victor, Altair Bueno, Emrah Bilbay and Vladimir@MarinPostma If you use nightly, allocators are very much usable already (and have been since 2021-ish). I figure most people that need allocators already use them, and you can too.
You can make your own allocators and your own allocator-aware collections, and these days even most of alloc/std collections already work custom allocators (#7), with String being the notable holdout (there's a history of attempts to make it happen, current HEAD here rust-lang/rust#101551).
Regarding allocators on stable: if you look at issues in this repository, you'll see we are still a long way off. Personally, I'd want to have some kind of MVP stabilized sooner, possibly at the expense of completely resolving questions such as #15.
Regarding involvement: I don't know of any easy things that need doing. #7 was such a list, but fruit has been picked.
Reacted by Pavel AtanasovRegarding allocators on stable: if you look at issues in this repository, you'll see we are still a long way off.
As a stopgap, I've seen many people adopt the use of https://github.com/zakarumych/allocator-api2 to get these apis in stable. This includes larger crates like hashbrown
Reacted by Pavel Atanasov, Saadi Save and studyingegretIn the spirit of seeking an MVP, is there anything blocking the stabilization of the "required" subset of
core::alloc::Allocator?For example, consider an
Allocatorwith only two methods:allocate()anddeallocate(). Are there any compatibility or stability concerns with stabilizing those two, and then leaving the optional methods for later?pub unsafe trait Allocator { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError>; unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout); }
The goal here would be to enable use of
Allocatorwith third-party crates that do their own alloc management, e.g. for arenas or customBox-like types.Reacted by ora-0, Berkus Decker, Taj Pereira, alloncm, Henry and Josiah BullLike @jmillikin, I'd also like to see minimal subset stabilized, although my minimal subset is a little larger:
As a user of allocator_api, I'd be quite happy with stabilizing a min_allocator_api with:
- The Allocator trait as is (except maybe
Allocator::by_ref, but maybe I just don't understand what it is for). - The allocator type parameter on std collections. I think this is almost implemented and the only critical thing missing is
String<A>. - Nothing else: no
vec_in!,DefaultIn,collect_in, etc. The reasoning here is that if someone really needs custom allocators for better speed/memory, they will be okay without all these helpers. Additionally, I'd argue that in codebases where performance is important, these helpers obscure what is going on.
Anyway, the current allocator_api +
String<A>would already be very useful to a lot of people.Can some of the workgroup members and designers here comment on they think is needed?
Reacted by Berkus Decker, ghosti3, Vladimir, Guillaume Raffin, Henry, tediou5, ju1ius, Declan Kelly, papill9, Victor and 11 more- The Allocator trait as is (except maybe
Yes please.
Enough time has passed, let’s get this merged.
Reacted by Pavel Atanasov, stkri, ghosti3, Leah Amelia Chen, Paval Shlyk, Lucas Thelen, Nathan Youngman, Jiening Yu, alloncm and Sofus Albert Høgsbro Rose- unpinned this issue
on Aug 8, 2026
I would like to come to the listed issues in the more or less indicated order. Linked issues are not necessarily confirmed, please consult the issues for more details.
AllocRef:GlobalAlloc::realloc’s parameters are backward #3,Support reallocating to a different alignment? #5: Support reallocating to a different alignment?AllocRefto take&selfReturnMaybeUninit<u8>rather thanu8#66/Introduce a byte-type #68: ReturnMaybeUninit<u8>rather thanu8/Introduce a byte typeAllocator aware types:
AllocRefonBox,Rc, andArc#54: ImplementAllocRefonBoxGlobalAlloc:GlobalAllocandAllocAllocRefonSystemwithoutGlobalAlloc#43: ImplementAllocRefonSystemwithoutGlobalAllocGlobalAllocwhen stabilizingAllocRefGlobalAllocwhenAllocRefis stabilized at least three months (two versions)Documentation:
AllocRefallocator#[global_allocator]*really* means #25: Define what#[global_allocator]really meansOther: