Re: Enum and Function Parameters Attributes -- No DIP Required
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
Re: Enum and Function Parameters Attributes -- No DIP Required
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 :) >
Re: Enum and Function Parameters Attributes -- No DIP Required
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 :)
Re: Enum and Function Parameters Attributes -- No DIP Required
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");
}
Re: Enum and Function Parameters Attributes -- No DIP Required
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.
