First, @SimonSapin, thanks for doing this! really, it was hard work, and most of these issues needed a push, and putting things into FCP is really a good way to push this.
Second, some of the issues in FCP feel like “design by PR”. Someone added an issue to rust-lang/rust, someone submitted a PR to address it, some people mentioned issues, suggested better designs, and in most cases nobody either cared to even answer these comments nor to submit follow up PRs.
So the grep “unstable” to FCP approach gives me the feeling that we are stabilizing things just to shorten a checklist that can be shown to managers, which makes me a bit uncomfortable.
At least, the proposal for FCP should come with a comment explaining exactly what will be stabilized. Often, the only way to know is to search for the PRs that actually implemented stuff and try to extract rationale from that, and then, having to skim through a github issue full of unanswered feedback. IMO such a summarizing comment should go beyond “what will be stabilized” and also summarize the discussion: open issues, alternatives considered, rationale, and maybe a snippet for the docs team so that they know what to do: are the docs already upstream? if so where? should they be reviewed? etc.
Two examples are Vec::remove_items method and the step_trait. I’ve read the issue, tried to follow PRs, and have no idea what is actually going to be stabilized, which work was done here, what happened with the many remaining open design issues most of them seem to never been neither addressed nor acknowledge beyond a couple of “thumbs up” on github here and there.
So maybe this is a process issue: @aturon, for rust-lang/rfcs discussion what’s being put in FCP is the RFC in the repo, but for tracking issues in rust-lang/rust, it is often impossible to know what the FCP is actually about because things change a lot from what was proposed in an RFC, if there ever was an RFC at all. I am not saying these things need a second RFC, but a summarizing comment should be the bare minimum IMO.
In any case, @SimonSapin, thanks again for doing this. All of these issues really needed a push. Doing the original design and implementation is fun, but writing docs, answering to feedback, and moving almost finished features into a finished state is boring work that many don’t like to do. So things remain in the “almost finished” limbo forever. I just wanted to point out that there is a difference between “almost finished” and “finished”, and that it is hard to tell in which states some of the issues in FCP actually are.
