Navigating the Rust RFC Process and Agile Development

Duplicate Issues become increasingly common

As of writing this, the Rust Lang repository on Github has almost 75000 issues in various states. I would suspect that many of those are somewhat overlapping or even plain duplicate issues. When someone comes to the Rust team with what they believe to be a new Internal Compiler Error or some other issue requiring triage, it then becomes the burden of the active community members to compare and contrast that issue with their individual and combined subject matter knowledge.

From experience of working somewhat in tandem with the 2018 major release cycle, simultaneous to the release of my book on Rust programming, the Rust development team moves very fast. This speed of development has not slowed down much. If you look at the features released in stable version 1.45 and scheduled for 1.46 or 1.47 you will find that there is a steady trickle of commonly desired and mutually agreed upon features that have been the work of many people over several years. Many of the "open" issues originate from 3 or 4 year old discussions that took a long time to come to point. These major feature releases run simultaneous to a steady stream of optimizations and bug fixes.

How to introduce a Feature that gets Implemented

Each of these compiler changes originate from a discussion on the forums or a chat room somewhere. My observation here is that there is a natural flow of development, and if a proposed feature runs counter to that flow, then it becomes very unlikely to be implemented. My most pragmatic observation here is that changes requiring extremely large code diffs will not get implemented. So my advice, if you want to introduce a new proposal is to familiarize yourself with how the compiler works in related areas.

An example from a feature I am waiting on would be the procedural macros API and specifically how span locations are held and propogated. I created a library that is very sensitive to changes in procedural macro spans. I have observed breaking changes in these areas between 1.43, 1.44, 1.45, 1.46, and 1.47. Researching these bugs myself has led me to find that much of the stable features in this area are not actually stable at all but rather placeholders or shims.

Spans are a particularly dark corner of procedural macros because they are normally used only for debugging and not intended for feature development. My case is an odd one and probably discouraged by a non-zero subset of the core development team. Depending on spans so heavily is like opening a restaurant that serves someone else's garbage on plates. It's not neighbourly and is definitely not sanitary.

Apart from my strange story about unstable features exposed on stable Rust, I would expect these sorts of things are generally classified as more or less "Undefined Behavior", and it is really not all that bad. Most people will only ever see changes in error messages from version to version, not unit test regressions. There is an open issue to stabilize more of this API in the #54725 issue which has been open for two years.