Thoughts on RFC/stabilization reform in 2019

internals policy
39

What the language team can help with here, and in particular with respect to the reference, is to require more elaborate stabilization reports so that it becomes easier for documentation writers to know what they are writing about. This is something I know the docs team feels and as a T-lang member I want to help facilitate things here to make parallel work possible.

The theme here is that I firmly believe that bandwidth and work done is not a linearly scaling resource -- you cannot just refocus community attention arbitrarily to fit your desires; people have different skills, know different things, are interested in different things, etc. We should try to unblock and allow more people work on more things rather than to stop working on language features. In fact, new language features may onboard new compiler developers.

I would also say that from the POV of making rollups, the PRs I see are mostly about improving diagnostics and improving perf.. I don't think implementing new features is the lionshare of where review time is being spent.

  • https://github.com/rust-lang/rfcs/pull/2360 -- this just needs someone from T-libs or T-compiler to take the initiative and fcp-merge or something; the RFC did see ~recent activity and moved away from a position which would have required T-lang approval to not requiring that... Implementation-wise this one is pretty easy... it mostly requires exposing an intrinsic + adding some docs (no more than the usual smallish libstd feature). This is currently blocked on "do we want this?".

  • inline assembly -- this is not accepted as an RFC and definitely not something "we already know we want" and the language team will likely be cautious here with any RFC.

  • custom test frameworks -- I think your strong impression is wrong; in fact, the internals link shows otherwise imo. Rather, I think what has been missing here is frameworks such as quickcheck and proptest actually trying these out to ensure the design is up to snuff.

My view is that a positive roadmap is good since it says what we want to do; for the other things, we should communicate more clearly that they won't be priorities, but also not forbidden. In my view, it is fine for an RFC to not see much action (e.g. a few comments and no team review) for a whole year -- when our priorities change, it is there and more polished.