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: #include C headers in D code
On Thursday, 12 April 2018 at 11:43:51 UTC, John Colvin wrote: On Wednesday, 11 April 2018 at 18:36:56 UTC, Walter Bright wrote: On 4/11/2018 3:25 AM, Atila Neves wrote: [...] That's right. There is no general solution. One can only look for common patterns and do those. For example, #define X 15 is a common pattern and can be reliably rewritten as: enum X = 15; If I understand it correctly, dpp doesn't do that. Instead, it runs the pre-processor on the source code, just like in C, so // test.dpp #define X 15 int foo() { return X; } becomes // test.d int foo() { return 15; } The upside of this approach: all macros just work, unless they use C (not C pre-processor, C proper) features that dpp can't handle. `sizeof(...)` is a special case that is handled in dpp.cursor.macro.translateToD and more could be added. The downside: macros can't be directly used outside .dpp files. Yes, I assumed it actually "expands" the macros, whereas it actually runs the preprocessor on dpp files: https://github.com/atilaneves/dpp/issues/30 I can see it perfectly matches the Atila's usecase, and I'm curious what are the other usecases for dpp?
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 18:36:56 UTC, Walter Bright wrote: On 4/11/2018 3:25 AM, Atila Neves wrote: I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance). If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!). That's right. There is no general solution. One can only look for common patterns and do those. For example, #define X 15 is a common pattern and can be reliably rewritten as: enum X = 15; If I understand it correctly, dpp doesn't do that. Instead, it runs the pre-processor on the source code, just like in C, so // test.dpp #define X 15 int foo() { return X; } becomes // test.d int foo() { return 15; } The upside of this approach: all macros just work, unless they use C (not C pre-processor, C proper) features that dpp can't handle. `sizeof(...)` is a special case that is handled in dpp.cursor.macro.translateToD and more could be added. The downside: macros can't be directly used outside .dpp files.
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.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Thursday, 12 April 2018 at 06:08:39 UTC, Kagamin wrote: On Wednesday, 11 April 2018 at 20:45:15 UTC, Dmitry Olshansky wrote: * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build. Template can call user code, but it wasn't tested for it, so the contract should be checked. What I mean is that for templates calling or not calling contracts depends on client code not the library. It’s just one consequence of template mechanism that has tons of other issues.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, 11 April 2018 at 20:45:15 UTC, Dmitry Olshansky wrote: * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build. Template can call user code, but it wasn't tested for it, so the contract should be checked.