Fortifying the process against feature bloat

internals policy
28

The response that this RFC has received from certain members of the community is really baffling to me, and seems to stem from ignorance about our policies on grammar. In the past we've merged changes to the grammar that in my opinion are at least as "bad" on the basis of the arguments against that RFC without even an RFC at all. In fact, I think our policy is that that kind of change simply doesn't need an RFC, and the RFC was overkill.

Here are two prominent examples:

  • Trailing +. T: 'static + is a grammatically correct bound.
  • Turbofish in types: impl<T> Option::<T> is a grammatically correct impl header.

Here is a valid way to write the main function signature in Rust:

fn main<>() where for<'a> (): 'a +, { }

Neither of these are accidents of any kind; they were both conscious changes made within the last 12 months, without an RFC process. And they all stem from the same basic underlying language policy: Rust has a very flexible grammar, trailing or leading separator and unnecessary characters are supposed to be permitted liberally, and extensions to its flexibility are considered bugfixes (for example, fn main::<>() doesn't parse, but probably should).

This policy was made with full awareness of the downsides (e.g. there are multiple, redundant syntaxes that have the same meaning), because we weighed the upsides as greater (especially the benefits to macros, but also often there is an underlying grammatical unification that a redundancy enables). Reiterating the downsides as applied to a particular case is not a compelling argument to make an exception to longstanding policy. There would have to be a very compelling counterargument which is specific to this case.

Its our ability to overrule the "votes" of the community (which have never been an actual part of the RFC process) that helps protect the longevity of the language, because we do better at pursuing a consistent vision than a shifting, temporary body made up of the people who happen to read a github issue would be able to. This RFC is, in my opinion, an excellent example of how our existing practices avoid the kind of negative outcomes you are worried about.

21 Likes