| Field | Value |
|---|---|
| DIP: | (number/id -- assigned by DIP Manager) |
| Author: | (your name and contact email address) |
| Implementation: | (links to implementation PR if any) |
| Status: | Draft |
Required.
Short and concise description of the idea in a few lines.
- Rationale
- Prior Work
- Description
- Breaking Changes and Deprecations
- Reference
- Copyright & License
- History
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 listed. 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) 2024 by the D Language Foundation
Licensed under Creative Commons Zero 1.0
The DIP Manager will supplement this section with links to forum discsusionss and a summary of the formal assessment.