Welcome to #t-libs/wg-allocators.
Description: Paving a path for a standard set of allocator traits to be used in collections!
@Erich Gubler :wave:
@Erich Gubler :wave: trying again...
Oh hi! :)
Okay, so, what are action items right now? Should I just comb over the Allocator API tracking issue and figure out how to summarize it?
I think the first thing for using the allocator_api in collections is to associate
Box<T, A: Alloc = Global>. #58457 did some work on this, but it requires a
Default bound as
DispatchFromDyn could only use
PhantomData as extra fields. Two days ago I made a PR to change this.
DispatchFromDyn now can take any ZST field with alignment of 1, thus
Default can be dropped as bound.
I made some tests on this: TimDiekmann@
DispatchFromDyn is checked) is used from the stage0 compiler, thus I had to dance with
Additionally we should decide, if we use
#[feature(allocator_api)] for both, the api and the association with the collections, or split it up.
After this is finished, I think we can split up the work and associate an allocator with other collections.
I just comb over the Allocator API tracking issue and figure out how to summarize it?
Maybe one issue per item on the wg-repository?
ZSTs are not the long term play, though... we still need a story for non-ZST
Box<T, A>. There was also the question whether the bound on A should be left out of the
struct Box definition.
Actually... without a bound that says
A is a ZST, how can
DispatchFromDyn be impl'ed?
No, you are right, but in unblocks the PR. To proceed and implement it the semver compatible way, it can be implemented for
I’ve added a README and filed a couple of issues in https://github.com/rust-lang/wg-allocators
Wow, in 17 hours we filed 11 issues with 32 comments! :grinning: