Roadmap

[TimDiekmann]

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:

• [x] ~#3,~ #5: Support reallocating to a different alignment?
• [x] #55: Change AllocRef to take &self
• [ ] ~#66/#68: Return MaybeUninit<u8> rather than u8/Introduce a byte type~
• [ ] Stabilize (this may take a while 😉 )

Allocator aware types:

• [x] Land rust-lang/rust#72314 (blocker for this section)
• [x] #54: Implement AllocRef on Box
• [ ] #7: Implement allocator aware collections
• [ ] #15: Additional traits for allocator aware types
• [ ] #39: try_ methods for containers

GlobalAlloc:

• [ ] #21: Coherent design of GlobalAlloc and Alloc
• [ ] #43: Implement AllocRef on System without GlobalAlloc
• [ ] soft-deprecate GlobalAlloc when stabilizing AllocRef
• [ ] deprecate GlobalAlloc when AllocRef is stabilized at least three months (two versions)

Documentation:

• [ ] #65: Clarify unsafe requirements of AllocRef A-Alloc Trait
• [ ] #47: Allocation promises with global AllocRef allocator
• [ ] #46: Add a section to the module documentation "What is a legal allocator"
• [ ] #25: Define what #[global_allocator] really means

Other:

• [x] #57: Rename AllocErr to AllocError

[TimDiekmann]

Updated OP.

[Wodann]

@TimDiekmann what are next steps? Are we waiting for potential feedback from users on our changes to the API before we proceed?

[TimDiekmann]

I'm currently testing the API with alloc-compose. I also testing out, on how well taking &self is working. While most allocators could use &self instead of &mut self this has a major downside: Cell is !Sync, so using internal mutability for Sync allocators have to use atomics or other structs, which introduce more overhead. For the same reason, Bump from bumpalo is also !Sync.

[Amanieu]

I think those downside of &self are actually advantages, see #55.

[SimonSapin]

• deprecate GlobalAlloc

Actively emitting deprecation warnings causes churn. What benefit does this bring in exchange?

• add #[doc(hidden)] to GlobalAlloc

GlobalAlloc is 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 using AllocRef instead is preferred.

[TimDiekmann]

Isn't that the point of deprecation warnings? Error::source was introduced in 1.30, Error::cause was deprecated in 1.33. I expect many more people to use the Error trait than the GlobalAlloc trait. Sure, we could also just leave GlobalAlloc alone :slightly_smiling_face:

Hiding its docs would be confusing to future readers of such code

Fair point.

[Wodann]

@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?

[TimDiekmann]

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.

[Wodann]

Thanks for cleaning up the roadmap and outstanding issues 👍

[TimDiekmann]

@Wodann FYI: We have started to implement #7.

[berkus]

Should AllocRef be renamed Allocator now or it's a different AllocRef?

[TimDiekmann]

https://github.com/rust-lang/wg-allocators/issues/76 https://github.com/rust-lang/rust/pull/79286

[MarinPostma]

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?

[yanchith]

@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 https://github.com/rust-lang/rust/pull/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.

[wmmc88]

Regarding 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

[jmillikin]

In the spirit of seeking an MVP, is there anything blocking the stabilization of the "required" subset of core::alloc::Allocator?

For example, consider an Allocator with only two methods: allocate() and deallocate(). 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 Allocator with third-party crates that do their own alloc management, e.g. for arenas or custom Box-like types.