The main point of this post is to announce that the DIP "Enum and
Function Parameter Attributes" [1], which has recently been under
Draft Review, is no longer required. The DIP will be feature will
be implemented without the need for the DIP. For posterity, the
following is a summary of how we arrived at this decision.
In the forum thread "UDAs Enum Members: Does it Require a DIP"
[2], Michael Franklin reported that Walter confirmed to him that
a DIP would be needed for the language to allow UDAs on enum
members. This clarified a previous statement Walter had made in
Pull Request 6161 [3] to add support for that feature.
Subsequently, a draft DIP was submitted proposing the feature,
and expanding it to allow for UDAs on function parameters.
Around the same time, a Pull Request was created to implement
support for UDAs on function parameters [4]. In the comment
thread for this PR, Andrei said that he and Walter "agree this
can be integrated without a DIP." When he realized a DIP had
already been submitted, he wanted to approve it "without too much
paperwork."
At this point, Andrei asked me about getting the DIP through the
process without the red tape. In the subsequent group
conversation, we came to the agreement that if a DIP goes through
the process, it needs to go from beginning to end as outlined in
the Procedure [5] and Guidelines documents [6]. Otherwise, an
announcement should be made in the forum that the DIP is not
needed and a rationale provided. In the end, the final decision
was left to me as DIP Manager.
The Procedure document requires a DIP when a feature nessecitates:
* Changes to the language itself, such as syntax/semantics
* Changes to the functional behavior of code generated by the
compiler
This proposal is a removal of a limitation on an existing feature
-- it neither modifies existing syntax nor requires deprecation
of any other language features. Nor does it change the behavior
of generated code. At the very least, some consideration may need
to be given to how existing introspection facilities behave in
the presence of UDAs in locations where they were not previously
allowed, but this alone does not appear to require a full DIP
review process to resolve.
The Procedure document also allows for an escape hatch from the
DIP process:
"The details outlined here are subject to change at any time, and
the DIP Manager or the Language Maintainers may allow for
exceptions which waive requirements or responsibilities at their
discretion."
This process is not set in stone. Flexibility is not a bad thing,
as long as an effort is made to maintain some level of
consistency. Given the ultimate preapproval of this DIP by Andrei
and Walter and their willingness to push it through the process
without hassle, I have no qualms in canceling the Draft Review
for this DIP.
[1] https://github.com/dlang/DIPs/pull/105
[2]
https://forum.dlang.org/thread/cltyrthdxkkfvuxqa...@forum.dlang.org
[3] https://github.com/dlang/dmd/pull/6161
[4] https://github.com/dlang/dmd/pull/7576
[5] https://github.com/dlang/DIPs/blob/master/PROCEDURE.md
[6] https://github.com/dlang/DIPs/blob/master/GUIDELINES.md
