| Field | Value |
|---|---|
| DIP: | (number/id -- assigned by DIP Manager) |
| Review Count: | 0 (edited by DIP Manager) |
| Author: | (your name and contact data) |
| Implementation: | (links to implementation PR if any) |
| Status: | Will be set by the DIP manager (e.g. "Approved" or "Rejected") |
Required.
Short and concise description of the idea in a few lines.
- Rationale
- Prior Work
- Description
- Breaking Changes and Deprecations
- Reference
- Copyright & License
- Reviews
Required.
A short motivation about the importance and benefits of the proposed change. An existing, well-known issue or a use case for an existing projects can greatly increase the chances of the DIP being understood and carefully evaluated.
Required.
If the proposed feature exists, or has been proposed, in other languages, this is the place to provide the details of those implementations and proposals. Ditto for prior DIPs.
If there is no prior work to be found, it must be explicitly noted here.
Required.
Detailed technical description of the new semantics. Language grammar changes (per https://dlang.org/spec/grammar.html) needed to support the new syntax (or change) must be mentioned. Examples demonstrating the new semantics will strengthen the proposal and should be considered mandatory.
This section is not required if no breaking changes or deprecations are anticipated.
Provide a detailed analysis on how the proposed changes may affect existing user code and a step-by-step explanation of the deprecation process which is supposed to handle breakage in a non-intrusive manner. Changes that may break user code and have no well-defined deprecation process have a minimal chance of being approved.
Optional links to reference material such as existing discussions, research papers or any other supplementary materials.
Copyright (c) 2019 by the D Language Foundation
Licensed under Creative Commons Zero 1.0
The DIP Manager will supplement this section with a summary of each review stage of the DIP process beyond the Draft Review.