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.


Reply via email to