-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rename the Alloc trait to AllocHandle #60591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @Kimundi (rust_highfive has picked a reviewer for you, use r? to override) |
@alexcrichton My understanding of our process is that we have no strict requirement for making any change to unstable APIs. However this one has been around for a long time. How do you think we should proceed with changes like this? |
This is a breaking change to an unstable API. Fixes rust-lang/wg-allocators#8 This change has some consensus. Landing it now will hopefully help clarify the vocabulary, including for discussion within the Allocators WG itself.
Perhaps adding a separately-feature-gated type alias would help with the transition? |
This is a trait, not a type. AFAIR stability and deprecation attributes have no effect on |
I don't personally have a preference for how the WG operates and lands code, I'd leave that up to y'all! I would personally consider any modifications to any unstable code ok to land at any time in terms of "scope", but I'd leave it up to the WG to determine how exactly the mode of operation should be done. |
ping from triage @rust-lang/libs any updates? |
This is a blocked on a decision from the WG, so tagging as such. |
No need to keep this open until unblocked. |
This is a breaking change to an unstable API.
Fixes rust-lang/wg-allocators#8
This change has some consensus in its issue. Landing it now will hopefully help clarify the vocabulary, including for discussion within the Allocators WG itself.