alloc: stabilise Allocator

[nia-e]

View all comments

See the current proposed stabilisation report for up-to-date information on the proposed stable API.

outdated former status

Stabilise a bare-minimum (dyn-incompatible, but could be in the future) Allocator trait, alongside Box::new_in(), Vec::new_in(), the System & Global Allocators, and a blanket impl of Allocator for T: GlobalAlloc. For now, we should take care not to make it possible to instantiate anything other than a Vec or Box with custom allocators; it's Probably Fine, but worth a proper look before we rush in.

The soundness requirements for implementors were tightened to the most restrictive ones we could reasonably want per a conversation with @RalfJung.

This was discussed extensively at the all-hands with an apparent tentative consensus from libs and participating ecosystem stakeholders that the current design can be extended backwards-compatibly to address almost all usecases.

cc @rust-lang/libs @rust-lang/libs-api @rust-lang/opsem

r? libs

[nia-e]

r? @Amanieu

[theemathas]

I believe the safety requirements are not yet correct. See #156544

[nia-e]

So, per today's libs meeting: @programmerjake the team was in favour of adding all the methods you suggest to the stabilisation, so hooray. We're waiting on #161115 merging (it has already been approved) which is itself just some typo fixes, but then this should be able to land. Hooray!

[nia-e]

I believe FCP is ready to be opened; the proposed-for-stabilisation bits are listed in the report. In brief:

• Allocator trait;
• Box<T, A> & Vec<T, A> + a couple methods on these;
• System & Global allocators.

The libs+libs-api ask is "are these indeed the APIs we want?" and the vibe seems to be positive. The lang ask is "can we commit to Box never being fundamental in A, given that changing this would be breaking later?" (context, context) and again the vibe appeared positive last time this was brought up ^^

[RalfJung]

Also on the lang side is committing to Box being "funny" around aliasing requirements -- it has them for A = Global (and maybe for A = NativeAllocator<T> in the future) but not for other allocators.

[Amanieu]

I believe FCP is ready to be opened; the proposed-for-stabilisation bits are listed in the report. In brief:

• Allocator trait;

• Box<T, A> & Vec<T, A> + a couple methods on these;

• System & Global allocators.

The libs+libs-api ask is "are these indeed the APIs we want?" and the vibe seems to be positive. The lang ask is "can we commit to Box never being fundamental in A, given that changing this would be breaking later?" (context, context) and again the vibe appeared positive last time this was brought up ^^

Thanks @nia-e for pushing this through!

@rfcbot merge lang,libs-api

[rust-rfcbot]

@Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @nikomatsakis
• @scottmcm
• @the8472
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nia-e]

cc also @rust-lang/libs-api + @rust-lang/lang

[traviscross]

Do we intend (now or later) to make any ABI guarantees about Box<T, A> where A ≠ Global?

[RalfJung]

I'd be fine with making guarantees for the case where A has trivial ABI. Beyond that -- probably not.

[traviscross]

Should we be firing improper_ctypes_definitions?

[nia-e]

I'm happy having them under that lint

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.