I want to bring back the discussion about modifying the
In #58457 there were several suggestions, on how to change/improve the
Dealloctrait: Most of the collections (incl.
Rc, etc.) does not need all methods from
Allocin order to work, only
deallocis needed for implementing
Drop. Other suggestions like
trait GetDeallocwhere also proposed.
Handleto the trait names to show that they are typically implemented for a reference or smart pointer or ZST: #58457 (comment)
AllocFrominto scope: #58457 (comment)
It’d be good to carefully go through past discussions (there are some in internals.rlo too) and file specific issues in the new repo about everything that is not resolved or implemented yet. @Tim Diekmann, would you like to do that?
Yup, I'll do that. Just to make sure I understood you right: not resolved means things like mentioned above and not implemented means things like
Box<T, A> etc.?
It’s a bit fuzzy, but in my mind “not resolved” means that a change was proposed but no consensus was reached (either because of disagreement or because the discussion just died off). “Not implemented” is when there’s consensus of yes we should totally do X, but no one made the PR
Alright. I'll start with a list of structs, which are the goal of this WG. Then I'll search through the dozens of topics on github and internals.rlo for suggestions, discussions etc. and make different issues where needed.
List of what structs?
This so far:
Box<T, A>(current PR: https://github.com/rust-lang/rust/pull/58457)
HashMap<K, V, S, A>(implement in hashbrown crate?)
BTreeMap<K, V, A>
HashSet<T, S, A>
ah, that should gain an allocator parameter
Yeah, thanks :sweat_smile:
hashbrown will be an “interesting” case, since the crates.io copy supports stable
Yup, I also thought this. But currently this is out of scope I guess.
Once more of the pieces are in place we can see what approach Amanieu wants to take
@Simon Sapin You may want to add some Labels to the repository? Especially for suggestions, discussions and tracking issues this would make sense.
Oh, I cannot assign labels anyway :blush:
I’m not sure what the labels should be
You should have an invite for the repo
Thanks, I'll put in some love soon
- Scott J Maddox brought
AllocFrominto scope: [#58457 (comment)](https://github.com/rust-lang/rust/pull/58457#issuecomment-475089881
There's also this comment which gives some more context and a more complete example. I really hope this use case is not forgotten. There are many custom allocators that depend on this kind of behavior (i.e. finding the allocator state from allocated pointer addresses).
Dealloc, it would complicate the
Vec implementations a bit (separating each function based on if it needs access to
Dealloc+Alloc), but it might be worth it to eke out the last bit of performance for specialized allocators. If deallocation is a no-op, for example, you want the compiler to throw away all code to access the Alloc instance; it might have trouble doing that in some cases, though, but it might be made easier if it's only
Dealloc. I don't know, though. It's just speculation.
@Scott J Maddox I'm currently on tracking the open discussions at github. If you don't mind you may file an issue at https://github.com/rust-lang/wg-allocators?
@Scott J Maddox the link doesn't work
https://github.com/rust-lang/wg-allocators/issues/9 is related, presumably
Scott J Maddox the link doesn't work
Hmm... That's odd. It works for me..
Oh, you mean the quoted one. I'll fix it.
Zulip added "quote" ;)
Scott J Maddox I'm currently on tracking the open discussions at github. If you don't mind you may file an issue at https://github.com/rust-lang/wg-allocators?
Thanks for filing this. Also thanks for the link to the example, now I really understand why you came up with this approach. We may need to bikeshed about the name, but this is another story.
BuildAlloc would be analogous to
BuildHasher for example.