| author | date-accepted | ticket-url | implemented |
|---|---|---|---|
Your name |
This proposal is discussed at this pull request. After creating the pull request, edit this file again, update the number in the link, and delete this bold sentence.
Here you should write a short abstract motivating and briefly summarizing the proposed change.
Give a strong reason for why the community needs this change. Describe the use case as clearly as possible and give an example. Explain how the status quo is insufficient or not ideal.
A good Motivation section is often driven by examples and real-world scenarios.
Specify the change in precise, comprehensive yet concise language. Avoid words like "should" or "could". Strive for a complete definition. Your specification may include,
- BNF grammar and semantics of any new syntactic constructs
- the types and semantics of any new library interfaces
- how the proposed change interacts with existing language or compiler features, in case that is otherwise ambiguous
Note, however, that this section need not describe details of the implementation of the feature or examples. The proposal is merely supposed to give a conceptual specification of the new feature and its behavior.
This section illustrates the specification through the use of examples of the language change proposed. It is best to exemplify each point made in the specification, though perhaps one example can cover several points. Contrived examples are OK here. If the Motivation section describes something that is hard to do without this proposal, this is a good place to show how easy that thing is to do with the proposal.
Detail how the proposed change addresses the original problem raised in the motivation.
Discuss possibly contentious interactions with existing language or compiler features.
Give an estimate on development and maintenance costs. List how this effects learnability of the language for novice users. Define and list any remaining drawbacks that cannot be resolved.
List existing alternatives to your proposed change as they currently exist and discuss why they are insufficient.
Explicitly list any remaining issues that remain in the conceptual design and specification. Be upfront and trust that the community will help. Please do not list implementation issues.
Hopefully this section will be empty by the time the proposal is brought to the steering committee.
(Optional) If accepted who will implement the change? Which other resources and prerequisites are required for implementation?
(Optional) This section provides an opportunty for any third parties to express their support for the proposal, and to say why they would like to see it adopted. It is not mandatory for have any endorsements at all, but the more substantial the proposal is, the more desirable it is to offer evidence that there is significant demand from the community. This section is one way to provide such evidence.