rfcs/text/2561-future-possibilities.md

• Feature Name: future_possibilities
• Start Date: 2018-10-11
• RFC PR: rust-lang/rfcs#2561
• Rust Issue: N/A. The RFC is self-executing.

Summary

Adds a "Future possibilities" section to the 0000-template.md RFC template that asks authors to elaborate on what natural extensions there might to their RFC and what future directions this may take the project into. This section asks authors to think holistically.

Motivation

The benefit for the author

Often times, when an RFC is written, the only thing an author considers may be the feature or change proposal itself but not the larger picture and context in which the RFC operates in. By asking the author to reflect on future possibilities, a larger degree of introspection within the author themselves may ensue. The hope is then that they may consider what larger effects their proposal may have and what subsequent proposals may be.

The author of this RFC has benefitted personally from writing future-possibilities sections (#2532, #2529, #2524, #2523, #2522, #2401, #2421, #2385, and #2306). Said written sections have also caused the current author to think more clearly about interactions in each of the written RFCs. If for no other reason, these sections offer a permanent space to idea-dump while writing an RFC.

For the team

The holistic perspective that a future-possibilities section can offer may also help the relevant sub-team to understand:

1. why something is proposed,
2. what the long term effects of said proposal is,
3. how said proposals fit with the product vision and roadmap that the team currently has.

For readers in general

More generally, the benefits for the teams described above also hold for all readers. In particular, a reader can better infer what sort of language Rust is turning into given the information in a future-possibilities section. Having such a section may also help generate interest in subsequent proposals which a different author may then write.

Guide-level explanation

This Meta-RFC modifies the RFC template by adding a "Future possibilities" section after the "Unresolved questions". The newly introduced section is intended to help the authors, teams and readers in general reflect holistically on the big picture effects that a specific RFC proposal has.

Please read the reference-level-explanation for exact details of what an RFC author will see in the changed template.

Reference-level explanation

The implementation of this RFC consists of inserting the following text to the RFC template after the section Unresolved questions:

Future possibilities

Think about what the natural extension and evolution of your proposal would be and how it would affect the language and project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how the this all fits into the roadmap for the project and of the relevant sub-team.

This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.

If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.

Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information.

Drawbacks

There are three main potential drawbacks:

The section will be unused

There's some risk that the section will simply be left empty and unused. However, in the recent RFCs written by the author as noted in the motivation, this has not been a problem. On the contrary, the very idea behind adding this section has come as a result of the experience gained by writing such future-possibilities sections in the aforementioned RFCs.

However, some of the RFCs written by the this RFC's author have not had such sections. Therefore, if an RFC leaves the newly introduced section empty, it is not the end of the world. The section is intended as encouragement and recommendation; it is not mandatory as no section in an RFC has ever really been.

Higher barrier to entry

As noted in RFC 2333, which was the last RFC to extend the template, the longer the template becomes, the more work there is to writing an RFC. This can raise the barrier to entry somewhat. However, we argue that it is worth the minor raise in the bar since it is OK for RFCs to leave the section empty.

Readers reacting negatively on the future possibilities

Another potential drawback is that readers of the RFC will focus too much on what is written in the future-possibilities section and not the actual proposal that is made in the RFC. This has not been the case in the RFCs mentioned in the motivation.

Rationale and alternatives

1. We could rephrase the section in various ways. It is possible to do such tweaking in the future.

2. We could rename it to "possible future work" or "future work" where the latter is more customary, but we have opted to use a section title that makes it more clear that the contents of the section are not what is accepted but only possibilities.

3. We could move the section up and down and around.

4. We could simply not have such a section and leave it up to each author. However, we argue here that it is beneficial to hint at the possibility of providing such a section. It might otherwise not occur to the author that such a section could be written.

Prior art

None of the languages enumerated in RFC 2333 have such a section proposed in this RFC. However, there are plenty of academic papers published which do contain sections pertaining to future possibilities. It is customary for such sections to be at the end of papers so as to not bore readers and keep them reading.

Unresolved questions

None as of yet.

Future possibilities

It may be the case that we would overhaul the RFC template completely if we undertake larger changes to the RFC process itself as is proposed in the staged-RFCs idea. However, we'll likely want to determine the answers and get the information that each section in the current template provides at some point during the lifecycle of a proposal.