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.
