Project Groups

[KodrAus]

Right now we have a lot of unstable surface area. We're starting to track that surface area in this project: https:/rust-lang/libs-team/projects/2

It's a reactive list of (most) of our current RFCs and tracking issues, organized into broad feature area. Maybe we can try arrange the columns in that project roughly into areas that we think could be managed by a project group?

[KodrAus]

cc @rust-lang/libs do you have any thoughts on trying to spin up groups to help move unstable features forwards?

[KodrAus]

There are other ways to slice these features too, like new APIs using MaybeUninit over &mut or NonNull over *mut that cover Box, Vec, Arc, Rc etc.

[KodrAus]

There’s also some big items like the Try trait and moving things to core that might benefit from some cross-cutting groups.

[LukasKalbertodt]

do you have any thoughts on trying to spin up groups to help move unstable features forwards?

This sounds like a good idea to me! I guess it would be a good idea to only tackle a few unstable features at a time, i.e. only having a few of those project groups at a time.

[KodrAus]

Looking at the project board, it looks like a few types have the most unstable APIs (this probably isn't very surprising):

• Iterator
• Result and Option
• [T] and str

Maybe forming a project group around Iterator would be worthwhile to try wrangle some of its unstable features and help decide what to accept going forward? Since a lot of extensions to iterator are combinators we have to first decide whether we want, which might be easier if there were some guidelines around what makes a useful combinator, and there's peripheral supporting traits to consider too. cc @cuviper would that be something that would interest you?

[cuviper]

Sure, I'm interested in Iterator. Are you asking me to write such guidelines, or just gathering a group to work on that together?

[KodrAus]

@cuviper I guess that depends on what you’re interested in and think is worthwhile! Do you think having a group that can be cc’ed and weigh in on Iterator APIs is worthwhile, or just having some supporting docs in the forge to consult? Or something else entirely?

[cuviper]

@KodrAus sorry I didn't reply sooner. I think some kind of "consulting" group makes sense -- I think the compiler has been using the term "expert map"? A doc could be nice, though I don't think I realistically have the time to write that. There's a lot of subjectivity in API design anyway, so we'll still need a group to weigh in.