I am missing the fields "stable/unstable/abandoned/always unstable" and "stabilized in rustc version". The reason for this is that it is sometimes hard to find out whether a feature has been stabilized or not or if it's even still under development.
The idea comes from python where similar fields exist in PEPs
Has this ever been discussed? I think it would add a lot of documentation value and also make the development process of rust more transparent. Also, why are some RFC writeups only found on github while others are on Introduction - The Rust RFC Book ?
There's a lot of inconsistencies, sometimes the base RFC text is updated (when abandoned, significantly changed post-FCP, amended by a later RFC, et cetera), but sometimes they are not. I've seen comments like "don't bother, we don't keep RFC texts up to date" but I've also seen drive-by updates that were accepted.
I like the idea, or some connection between the RFCs and the eventual spec.
Unless you have a specific example, I think that's just the difference between RFCs accepted and merged by FCP and those not-yet accepted or never accepted.
Yeah I just realized that I never actually checked. It's just that in the related issues sometimes the rfc book is referenced and sometimes a markdown page on github is referenced. But they very well might be the same.
That's a shame. It's really nice to have a well documented history that just shows the endpoints of the developlment of a feature. Python PEPs do this nicely because they get updated and even sometimes document the broad strokes about discussions and controversies that were had around the PEP.
I think past RFCs should be updated to either reflect the final version, or have huge flashing warning that they're obsolete.
The RFCs come up in Google when searching for Rust features. There's also a book-like list of them, which can be easily mistaken for an official reference.
