www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Enum and Function Parameters Attributes -- No DIP Required

reply Mike Parker <aldacron gmail.com> writes:
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
Apr 12
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 12 April 2018 at 08:28:17 UTC, Mike Parker wrote:
 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.

 [...]
If there's a clear need for something and little dissent, it makes sense to short-circuit the process like this.
Apr 12
prev sibling next sibling parent arturg <var.spool.mail700 gmail.com> writes:
On Thursday, 12 April 2018 at 08:28:17 UTC, Mike Parker wrote:
 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."

 [4] https://github.com/dlang/dmd/pull/7576
will templates be supported? dont know, maybe something like this example: void test(T)(T t) { } void test2(Args...)(Args args) { } void main() { // uda declaration as a ct-param test!( (1) int)(1); test2!( (1) int, (2) string)(1, "test"); test!( (1))(1); // inferred type but provided uda? 1.test!( (1) int); 1.test2!( (1) int, (2) string)("test"); 1.test!( (1)); // inferred type but provided uda? // or alternatively as a rt-param test( (1) 1); // inferred type but provided uda? ( (1) 1).test; test2( (1) 1, (2) "test"); test!(int)( (1) 1); test2!(int, string)( (1) 1, (2) "test"); }
Apr 12
prev sibling parent reply Ali <fakeemail example.com> writes:
On Thursday, 12 April 2018 at 08:28:17 UTC, Mike Parker wrote:
 * 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.
So if this change doesn't change anything, why is it called a change? An addition is a type of change and you make it sound as if DIPs are only required for breaking changes I think any change or addition (transparent, minor, simple) that add capabilities to the language or to the standard library should have been a DIP If the process is too heavy for small changes, add a simple path in the process for small changes, instead of completely ignoring the process, add a fast track process for minor changes Anyway, good luck, and happy to see D adding features :)
Apr 12
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
DIP is an abbreviation for D Improvement Proposals, so in theory we should
have DIP for every bugfix (if I follow your logic), because it is an
improvment :D. No I do not agree with this. UDAs has been added before DIPs
and as original author said the definition of UDAs (
https://dlang.org/spec/attribute.html#UserDefinedAttribute) is lame (
https://forum.dlang.org/post/k7afq6$2832$1 digitalmars.com).So I would say
we are talking about fixing implementation not a language change anyway.

On Thu, Apr 12, 2018 at 5:18 PM, Ali via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 12 April 2018 at 08:28:17 UTC, Mike Parker wrote:

 * 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.
So if this change doesn't change anything, why is it called a change? An addition is a type of change and you make it sound as if DIPs are only required for breaking changes I think any change or addition (transparent, minor, simple) that add capabilities to the language or to the standard library should have been a DIP If the process is too heavy for small changes, add a simple path in the process for small changes, instead of completely ignoring the process, add a fast track process for minor changes Anyway, good luck, and happy to see D adding features :)
Apr 12
parent Ali <fakeemail example.com> writes:
On Thursday, 12 April 2018 at 22:41:16 UTC, Daniel Kozak wrote:
 DIP is an abbreviation for D Improvement Proposals, so in 
 theory we should have DIP for every bugfix (if I follow your 
 logic), because it is an improvment :D.
I see your point, but that was not my logic My key point, was if this was not turned into a DIP because the DIP process is too heavy, fix the DIP process, dont fix this by avoiding the DIP process Note that in this case, there was a DIP which was cancelled So this was far from being similar to a bug fix And the difference between bug fix and enhancement is i hope is clear Again, I was motivated to make this comment, because I can see how much Andrei and Walter wants the community to commit to the dip process, i've seen Andrei replying to many by suggesting to turn posts into DIPs for stronger commitment
Apr 12