digitalmars.D.announce - Enum and Function Parameters Attributes -- No DIP Required
- Mike Parker (57/57) Apr 12 2018 The main point of this post is to announce that the DIP "Enum and
- Joakim (3/10) Apr 12 2018 If there's a clear need for something and little dissent, it
- arturg (21/28) Apr 12 2018 will templates be supported?
- Ali (12/19) Apr 12 2018 So if this change doesn't change anything, why is it called a
- Daniel Kozak (9/27) Apr 12 2018 DIP is an abbreviation for D Improvement Proposals, so in theory we shou...
- Ali (13/16) Apr 12 2018 I see your point, but that was not my logic
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 2018
Joakim <dlang joakim.fea.st> 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 2018
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/7576will 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 2018
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 2018
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 2018
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 2018