Enum and Function Parameters Attributes -- No DIP Required

[Mike Parker]

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/cltyrthdxkkfvuxqasqw@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