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:

• GlobalAlloc::realloc’s parameters are backward #3, Support reallocating to a different alignment? #5: Support reallocating to a different alignment?
• Change AllocRef to take &self #55: Change AllocRef to take &self
• Return MaybeUninit<u8> rather than u8 #66/Introduce a byte-type #68: Return MaybeUninit<u8> rather than u8/Introduce a byte type
• Stabilize (this may take a while 😉 )

Allocator aware types:

• Land Stability annotations on generic parameters (take 2) rust#72314 (blocker for this section)
• Implement AllocRef on Box, Rc, and Arc #54: Implement AllocRef on Box
• Tracking Issue for structs which needs an allocator #7: Implement allocator aware collections
• Additional traits for allocator aware types #15: Additional traits for allocator aware types
• try_* methods for containers #39: try_ methods for containers

GlobalAlloc:

• Coherent design of GlobalAlloc and Alloc #21: Coherent design of GlobalAlloc and Alloc
• Implement AllocRef on System without GlobalAlloc #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:

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

Other:

• Rename AllocErr to AllocError #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 🙂

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 👍