Stabilize `dyn Allocator`

[joshtriplett]

View all comments

PR #156882 is stabilizing Allocator.

In order to do so more easily, it's marking Allocator as not dyn-compatible, to reserve the options of either adding features that currently prevent dyn-compatibility or marking it dyn-compatible and requiring those features to use an extension trait instead.

In order to make this decision and the stabilization decision in parallel, I'm filing this issue for a separate FCP.

Based on the discussion in the All Hands, it seemed like there weren't any features that we couldn't do via the extension trait solution, allowing the base trait to be dyn-compatible. So, in this issue, I'm proposing that we remove the limitation on Allocator and allow dyn Allocator.

[joshtriplett]

@rfcbot merge libs-api

[rust-rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

Concerns:

• impl-clone-dyn-allocator-resolution (Stabilize dyn Allocator #156906 (comment))

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!

See this document for info about what commands tagged team members can give me.

[desiderautumn]

Would it be ideal for this question to be resolved prior to the stabilization of Allocator, or is there no particular time pressure here?

[theemathas]

Initially, the thought was that dyn-compatibility can be decided later. However, #156920 complicates the situation significantly, and we might have to decide before stabilization.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔