I and apparently other members of the Library team were not aware or did not remember that when we discussed the creation of the Allocators Working Group.
RFC 1398 was accepted in 2016 with a trait for memory allocators. It mentions but does not fully specify making Vec and other containers generic over the allocator type. Since then there has been discussion that is both lengthy (412 comments so far in https://github.com/rust-lang/rust/issues/32838 alone) and fragmented (with a number of threads on this forum), but not a lot of concrete progress. (Other than for GlobalAlloc and #[global_allocator], which specifically left out allocator-generic containers.)
I don’t remember who first suggested an Allocators Working Group (sorry!) but I felt that having a dedicated issue tracker where specific questions can be discussed separately and marked as resolved separately would be very helpful.
After some discussion in Gauging Interest for an Allocator Trait Working Group, we created the rust-lang/wg-allocators repository on GitHub and the t-libs/wg-allocators stream on Zulip.
Now, this thread mentions domain working groups. I’m not sure wg-allocators qualifies as one in the sense that the 2018 roadmap talks about. And this group already exists to some extent, so this isn’t really an application. Still, this list of questions raises good points so I’ll try to answer them for this group.
Some of this is my personal opinion.
- What value do you want to bring to the project?
Give users of standard library containers more control over heap memory allocation, and enable more use case. Finish designing and implementing a long-standing accepted RFC.
This is an item the 2019 roadmap.
- Why should it be put into place?
The discussion to resolve all the associated questions has proven too large for a single tracking issue.
- What is the working group about?
An allocator trait and allocator-generic containers based on this trait.
- What is the working group not about?
Defining scope more precisely remains to be done. Different people have expressed different desires so far, but it might be better to try to agree on some goals and non-goals.
- Is your WG long-running or temporary?
- If it is temporary, when should it spin down?
- What is your long-term vision?
Temporary, though I have no idea if it won’t end up running for a long time.
The expected outcome is an RFC (or a few RFCs). The group should spin down, to be determined, either when the RFC(s) are accepted, or implemented, or stabilized.
(A possible alternative outcome is a “blessed” crate on crates.io that provides relevant functionality, and consensus that it doesn’t strictly need to be in the standard library. This is more likely IMO if Compat of adding parameters to stable types · Issue #1 · rust-lang/wg-allocators · GitHub doesn’t work out and we need to have separate container types regardless. The standard library could depend on that crate and expose wrappers, like it now does for https://crates.io/crates/hashbrown and HashMap.)
- How do you expect the relationship to the project be?
I expect similar to that of an individual contributor for smaller features: submit RFC(s) and implementation PR(s) and follow the usual process for them.
- How do you want to establish accountability?
Accountability for what?
- Which other WGs do you expect to have close contact with?
Unclear. Possibly none, unless they have use cases for these features.
- What are your short-term goals?
File separate issues in Issues · rust-lang/wg-allocators · GitHub for remaining design questions, and get discussion going. This has already started.
- Who is the initial leadership?
- This is preferably multiple persons
In Gauging Interest for an Allocator Trait Working Group - #16 by ErichDonGubler, @ErichDonGubler volunteered to be a facilitator. This term is used after blog posts by Manish and by Niko.
However I feel that it’s not clear what the responsibilities are or should be. Some “How to start/run a WG” guidance would be appreciated here.
While I am interested in this topic, I lack bandwidth and am specifically not volunteering to be a leader or facilitator. (Though I am the de-facto contact with the Library team.)
- How do you intend to make your work accessible to outsiders?
Anyone is welcome to participate to discussion on the repository or on Zulip. So far there is no synchronous meeting or formal membership. It’s undecided whether there should be, see Decision making in the WG · Issue #20 · rust-lang/wg-allocators · GitHub.
- Everything that is already decided upon
- e.g. places to chat, write and mail
- Issues · rust-lang/wg-allocators · GitHub
- https://rust-lang.zulipchat.com/#narrow/stream/197181-t-libs.2Fwg-allocators for lower-latency chat, though IMO any conclusion or consensus that comes up there should be brought back to the issue tracking for more visibility.
- Where do you need help?
Some guidance or good precedent in other WGs to look at about whether or how to have formal membership, how to build consensus and make decisions (within the WG before bringing them to the wider Rust project and community through an RFC), and more generally what it means to lead on facilitate a WG.
- Preferred way of contact/discussion
Maybe the issue tracker? I’ve subscribed to be notified of everything in it, and suggested in the README that people who are interested do the same.