| Field | Value |
|---|---|
| DIP: | (number/id) |
| RC# | 0 |
| 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") |
Short and concise description of the idea in a few lines.
Optional sections containing links to existing discussions, research papers or any other supplementary materials.
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.
State 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.
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.
A more practical explanation of DIP semantics should be given by showing several examples of its idiomatic application. Inspecting vivid code examples is usually an easier & quicker way to evaluate the value of a proposal than trying to reason about its abstract description.
Copyright (c) 2017 by the D Language Foundation
Licensed under Creative Commons Zero 1.0
Will contain comments / requests from language authors once review is complete, filled out by the DIP manager - can be both inline and linking to external document.