www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RFC: 2 enhancement DIPs that need feedback

reply Meta <jared771 gmail.com> writes:
Hello, I've been working on a couple different DIPs that propose 
various enhancements to D.

1. Implicit Type Template Instantiation via Constructors with 
Dennis Korpel:
https://forum.dlang.org/post/wxfvbvutqjwvfrvuksua forum.dlang.org

2. Tuple Unpacking Syntax with Timon Gehr and Nick Trealeven:
https://forum.dlang.org/post/mjzhwbwuvnfqimwazzxq forum.dlang.org

DIP 1 has gotten a little bit of feedback, but not much, and DIP 
2 was just posted today. If you have an interest in either of 
these features and want to see them in D, it would be greatly 
appreciated if you could leave comments in either thread so we 
can get a feel for whether these DIPs are worth pushing through 
the proposal process.

**Note that DIP 1 is in the DIP Drafts forum, and DIP 2 is in the 
DIP Ideas forum. The regular rules regarding feedback on DIPs in 
each forum apply.**

Without adequate feedback, they will likely not move forward, so 
please read them over and leave any thoughts you might have!

Thank you.
May 12
parent reply Monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 12 May 2025 at 23:13:23 UTC, Meta wrote:
 Hello, I've been working on a couple different DIPs that 
 propose various enhancements to D.

 [...]
I think dip 2 is far more important, dip 1 has work arounds and I dislike the complexity around constructors as is
May 12
parent reply Meta <jared771 gmail.com> writes:
On Monday, 12 May 2025 at 23:23:27 UTC, Monkyyy wrote:
 On Monday, 12 May 2025 at 23:13:23 UTC, Meta wrote:
 Hello, I've been working on a couple different DIPs that 
 propose various enhancements to D.

 [...]
I think dip 2 is far more important, dip 1 has work arounds and I dislike the complexity around constructors as is
Please leave your feedback in the respective threads I linked. Thank you!
May 12
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 12 May 2025 at 23:29:36 UTC, Meta wrote:
 On Monday, 12 May 2025 at 23:23:27 UTC, Monkyyy wrote:
 On Monday, 12 May 2025 at 23:13:23 UTC, Meta wrote:
 Hello, I've been working on a couple different DIPs that 
 propose various enhancements to D.

 [...]
I think dip 2 is far more important, dip 1 has work arounds and I dislike the complexity around constructors as is
Please leave your feedback in the respective threads I linked. Thank you!
I'll drop a comment here anyway because it doesn't fit to the DIP section I think. D really needs "variable declaration" as expressions. My opinion is that here you are again faced to a special case that the general case, i.e "variable declaration" as expression, would have solved. ```d (auto a, auto b) = call(); // two VarDeclExp in the LHS ``` Let me enumerate all the cases we have now. You can exceptionally declare variable as expression in - the IfStatement - the WithStatement - the WhileStatement - the SwitchStatement and now what is proposed is another case: as tuple element. Cant just people open their eyes ? That language construct tends to become a well defined expression. A little joke to finish, I occasionally use that thing to count if something new is worth: ```d printf("for the %dnth time\n", static int count++); ``` Yeah that kind of things work when you have "variable declaration" as expression.
May 13
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/13/25 11:04, Basile B. wrote:
 On Monday, 12 May 2025 at 23:29:36 UTC, Meta wrote:
 On Monday, 12 May 2025 at 23:23:27 UTC, Monkyyy wrote:
 On Monday, 12 May 2025 at 23:13:23 UTC, Meta wrote:
 Hello, I've been working on a couple different DIPs that propose 
 various enhancements to D.

 [...]
I think dip 2 is far more important, dip 1 has work arounds and I dislike the complexity around constructors as is
Please leave your feedback in the respective threads I linked. Thank you!
I'll drop a comment here anyway because it doesn't fit to the DIP section I think. D really needs "variable declaration" as expressions. My opinion is that here you are again faced to a special case that the general case, i.e "variable declaration" as expression, would have solved. ```d (auto a, auto b) = call(); // two VarDeclExp in the LHS ``` ...
No, this syntax would not work just because there would be variable declaration as expression. You still need a) tuple literals b) dedicated unpacking logic.
 Let me enumerate all the cases we have now. You can exceptionally 
 declare variable as expression in
 
 - the IfStatement
 - the WithStatement
 - the WhileStatement
 - the SwitchStatement
 
 and now what is proposed is another case: as tuple element.
 ...
Actually that is not true. The DIP does not propose dedicated tuple syntax to be added. It's just about unpacking. Anyway, it's not like that blocks work on your vision at all.
 Cant just people open their eyes ? That language construct tends to 
 become a well defined expression.
 
 A little joke to finish, I occasionally use that thing to count if 
 something new is worth:
 
 ```d
 printf("for the %dnth time\n", static int count++);
 ```
 
 Yeah that kind of things work when you have "variable declaration" as 
 expression.
Go ahead and implement it. It's harder, not a simplification. Suddenly, whenever you are parsing any expression, you will have to take into account the possibility that it is actually a variable declaration. The way DMD deals with lvalues is also ill-equipped to allow this to be added easily. Furthermore, you now have to do proper scope handling for short-circuiting operations.
May 14
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 14 May 2025 at 16:56:23 UTC, Timon Gehr wrote:
 On 5/13/25 11:04, Basile B. wrote:
 [...]
No, this syntax would not work just because there would be variable declaration as expression. You still need a) tuple literals b) dedicated unpacking logic.
 [...]
Actually that is not true. The DIP does not propose dedicated tuple syntax to be added. It's just about unpacking. Anyway, it's not like that blocks work on your vision at all.
 [...]
Go ahead and implement it. It's harder, not a simplification. Suddenly, whenever you are parsing any expression, you will have to take into account the possibility that it is actually a variable declaration. The way DMD deals with lvalues is also ill-equipped to allow this to be added easily. Furthermore, you now have to do proper scope handling for short-circuiting operations.
It **is** implemented but not in **D**. I see what would be the problem with D or rather I see what "you guys think" the problem would be. I think that this is wrong, it's not like if the parser does not already have to perform an arbitrary count of lookups in certain situations.
May 16
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/16/25 13:24, Basile B. wrote:
 On Wednesday, 14 May 2025 at 16:56:23 UTC, Timon Gehr wrote:
 On 5/13/25 11:04, Basile B. wrote:
 [...]
No, this syntax would not work just because there would be variable declaration as expression. You still need a) tuple literals b) dedicated unpacking logic.
 [...]
Actually that is not true. The DIP does not propose dedicated tuple syntax to be added. It's just about unpacking. Anyway, it's not like that blocks work on your vision at all.
 [...]
Go ahead and implement it. It's harder, not a simplification. Suddenly, whenever you are parsing any expression, you will have to take into account the possibility that it is actually a variable declaration. The way DMD deals with lvalues is also ill-equipped to allow this to be added easily. Furthermore, you now have to do proper scope handling for short-circuiting operations.
It **is** implemented but not in **D**. ...
I don't know why you seem to think I am not aware of this. Clearly I meant go ahead and implement it in DMD, and deal with the politics and technical debt, in addition to refactoring an evolving code base that was not originally developed with this feature in mind. I don't think it is a bad idea, it's just not what I had chosen to invest my increasingly scarce spare time in. IIRC Andrei also wanted this, so I don't think it is impossible for this to make it into the language. It's just that my analysis of the cost/benefit ratio makes this an unappealing prospect to me at the moment.
 I see what would be the problem with D or rather I see what "you guys 
 think" the problem would be. I think that this is wrong, it's not like 
 if the parser does not already have to perform an arbitrary count of 
 lookups in certain situations.
There is no fundamental problem, given infinite resources. I just went with a less controversial incremental language addition that was also simple enough to implement and improves language ergonomics meaningfully. Anyway, I don't understand why you are approaching this in such a belligerent manner. (My eyes are open, thank you very much, it seems that did not magically implement your feature in DMD though.) Just understand we have to start somewhere and I am not willing to maintain my own fork of the language indefinitely until it reaches your arbitrary standard of orthogonality of features. Again, tuple unpacking does not conflict at all with variable declarations within expressions, and variable declarations within expressions, even if you add tuple literals with dedicated unpacking assignment logic, actually do not directly cover key use cases such as unpacking a foreach loop variable, unpacking at global scope, or unpacking in a function argument list. So again, you are just asking: "Why did you not do significantly more work to also cover use cases like `if((auto a = foo()) && a.bar()){}` ?" It's not hard to understand why I did not do it, it's basic economics. x) The unpacking DIP would not even be in the state it is now without Meta and Nick stepping up to help push it over the finish line. I did the basic implementation of UnpackDeclaration in _2018_! It's about time for this feature to land, and I am not going to entertain the idea of delaying it just because you seem to think rewriting big portions of DMD would have been so much easier.
May 16
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/16/25 18:32, Timon Gehr wrote:
 I am not going to entertain the idea of delaying it just because you 
 seem to think rewriting big portions of DMD would have been so much easier.
Even just getting tuple assignment to work is annoying: https://github.com/tgehr/dmd/pull/12#pullrequestreview-2779380671 Feel free to fix the limitations of that PR, I think it's a necessary prerequisite to supporting tuple unpacking via variable declaration as expression.
May 16
parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 16 May 2025 at 16:43:05 UTC, Timon Gehr wrote:
 On 5/16/25 18:32, Timon Gehr wrote:
 I am not going to entertain the idea of delaying it just 
 because you seem to think rewriting big portions of DMD would 
 have been so much easier.
Even just getting tuple assignment to work is annoying: https://github.com/tgehr/dmd/pull/12#pullrequestreview-2779380671 Feel free to fix the limitations of that PR, I think it's a necessary prerequisite to supporting tuple unpacking via variable declaration as expression.
You really dont seem to get the point I tried to raise. It's not directly about tuples. It's about the fact that variable declarations as expressions would solve the problem directly. Bonus that would make the grammar much more simple for plenty of Statements. That's just astonishing how people refuse to see that. I mean, are you (plurally) blind ?
May 16
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 5/16/25 23:45, Basile B. wrote:
 On Friday, 16 May 2025 at 16:43:05 UTC, Timon Gehr wrote:
 On 5/16/25 18:32, Timon Gehr wrote:
 I am not going to entertain the idea of delaying it just because you 
 seem to think rewriting big portions of DMD would have been so much 
 easier.
Even just getting tuple assignment to work is annoying: https://github.com/tgehr/dmd/pull/12#pullrequestreview-2779380671 Feel free to fix the limitations of that PR, I think it's a necessary prerequisite to supporting tuple unpacking via variable declaration as expression.
You really dont seem to get the point I tried to raise.
I am capable of understanding the points you are putting out, you are just not correct about the ones that are most important in the context of this tread.
 It's not directly about tuples.
You are making some statements and implications about tuple unpacking that are not true in the context of D/DMD, this is what I was primarily responding to, but I am happy to contradict your other incorrect statements and agree with any correct ones.
 It's about the fact that variable declarations as 
 expressions would solve the problem
"The problem" being tuple unpacking, so actually it turns out that your point is, at least in part, directly about tuples.
 directly.
- It is not true that that would solve the problem "directly", you still need to do all the unpacking logic, and more, on top. It does not suffice to be able to declare variables anywhere in an expression. - While it can work in theory, and the unpacking DIP is forward-compatible with a design that does work this way, it is not an efficient step towards achieving the goal of unpacking given the actual current circumstances we are faced with.
 Bonus that would make the 
 grammar much more simple for plenty of Statements.
This is also not true. Instead of "IfCondition", they would state "Expression". And the "IfCondition" rules would be moved over to "Expression". Big deal. The grammar stays basically at the same level of complexity and any simplifications that are made are incidental and unrelated to the feature. Likely, the grammar would even get a bit more blown up because actually it can be awkward to make a variable declaration inline and have to always refer to it directly in the expression, so probably you'd want something that is at least as capable as a let binding (which C++17 has introduced as a special case in some statements). Anyway, parsing this is not even the primary issue, though I anticipated some resistance anyway due to the pervasiveness of the contexts in which the new grammar rule would apply and some (mostly misguided) concerns about parser performance. The biggest part of the effort here is making the new expression type work sensibly in all contexts in which expressions can occur, in a big code base that already assumes that expressions will not declare named variables. One challenge with the implementation of this feature is that it is not fully self-contained, the contexts have to play ball somehow. This is of course something that is completely invisible if you build a new language that nobody is already using, as a greenfield effort where one of the design goals is to support variable declarations anywhere.
 That's just astonishing how people refuse to see that.
This claim is a pure hallucination. Besides exaggerations of supposed benefits to abstract notions such as grammar complexity as well as their significance, I don't see any posts here that are particularly confused about how variable declarations as expressions would work or what it would do to the grammar, parser, or semantic analysis routines. It's not some secret knowledge, it's just not something that D has done. It does seem like you have a distorted view of the benefit/cost ratio that others should assign to this feature in D. I would happily use it now and then if it were added, and would have integrated it with tuple unpacking if it had already been available. However, before anything like this has any chance to be added there will be weeks of forum debate. If you recall, Guido van Rossum gave up his position as Python's BDFL over a somewhat similar feature, so I will be astonished right back at you for not seeing the potential for this to create a huge amount of drama that is not conducive to the current primary goal of being able to unpack tuples. x) Declaring variables anywhere in an expression in a D program just does not rank very high on my list of priorities.
 I mean, are you (plurally) blind ?
It is interesting how you have not implemented this in DMD yourself, yet expect people to have done it unless they have some sort of handicap.
May 16
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2025 9:56 AM, Timon Gehr wrote:
 Go ahead and implement it. It's harder, not a simplification. Suddenly,
whenever 
 you are parsing any expression, you will have to take into account the 
 possibility that it is actually a variable declaration. The way DMD deals with 
 lvalues is also ill-equipped to allow this to be added easily. Furthermore,
you 
 now have to do proper scope handling for short-circuiting operations.
There's also a problem with handling destruction of the declaration.
May 20
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 21 May 2025 at 04:55:50 UTC, Walter Bright wrote:
 On 5/14/2025 9:56 AM, Timon Gehr wrote:
 Go ahead and implement it. It's harder, not a simplification. 
 Suddenly, whenever you are parsing any expression, you will 
 have to take into account the possibility that it is actually 
 a variable declaration. The way DMD deals with lvalues is also 
 ill-equipped to allow this to be added easily. Furthermore, 
 you now have to do proper scope handling for short-circuiting 
 operations.
There's also a problem with handling destruction of the declaration.
I dont think so. I consider that, based on default initialization, which has to always happen, even if an AndAnd LHS has evaluated to true and then that the RHS is a VarDeclExp, then its matching variable is always destructible. To be clear the AST for ```d if (MyStruct ms0 = call0) && (MyStruct ms1 == call1) {} ``` is to be thought as ```d { MyStruct ms0; // def init, ms0 is in valid state MyStruct ms1; // def init, ms1 is in valid state if (ms0 = call0) && (ms1 == call1) {} // ... // right before the end of the scope ms0.__dtor(); ms1.__dtor(); } ``` In practice that scenario almost never happen, since VarDeclExp are 99% of the time used for pointers or simple numeric types.
May 22
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 22 May 2025 at 09:31:51 UTC, Basile B. wrote:
 On Wednesday, 21 May 2025 at 04:55:50 UTC, Walter Bright wrote:
 On 5/14/2025 9:56 AM, Timon Gehr wrote:
 Go ahead and implement it. It's harder, not a simplification. 
 Suddenly, whenever you are parsing any expression, you will 
 have to take into account the possibility that it is actually 
 a variable declaration. The way DMD deals with lvalues is 
 also ill-equipped to allow this to be added easily. 
 Furthermore, you now have to do proper scope handling for 
 short-circuiting operations.
There's also a problem with handling destruction of the declaration.
I dont think so. I consider that, based on default initialization, which has to always happen, even if an AndAnd
OrOr
 LHS has evaluated to true and then that the RHS is a 
 VarDeclExp, then its matching variable is always destructible.

 To be clear the AST for

 ```d
 if (MyStruct ms0 = call0) && (MyStruct ms1 == call1) {}
 ```

 is to be thought as

 ```d
 {
     MyStruct ms0; // def init, ms0 is in valid state
     MyStruct ms1; // def init, ms1 is in valid state
     if (ms0 = call0) && (ms1 == call1) {}
```d if ((ms0 = call0) || (ms1 == call1)) {} ```
     // ...
     // right before the end of the scope
     ms0.__dtor();
     ms1.__dtor();
 }
 ```

 In practice that scenario almost never happen, since VarDeclExp 
 are 99% of the time used for pointers or simple numeric types.
plus do people often use `opCast!bool` ?
May 23
parent Dom DiSc <dominikus scherkl.de> writes:
On Friday, 23 May 2025 at 07:15:05 UTC, Basile B. wrote:

 plus do people often use `opCast!bool` ?
Yes, because any "if(x)" is lowered to "if(x.opCast!bool)" for all custom types. Same for every occurence of !x, loweredto !(x.opCast!bool).
May 23
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 13 May 2025 at 09:04:07 UTC, Basile B. wrote:
 ```d
 (auto a, auto b) = call(); // two VarDeclExp in the LHS
 ```
Please no... If we can't have `auto (a, b) = call();` then we better not have it at all...
May 20
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 May 2025 at 09:33:40 UTC, Dejan Lekic wrote:
 On Tuesday, 13 May 2025 at 09:04:07 UTC, Basile B. wrote:
 ```d
 (auto a, auto b) = call(); // two VarDeclExp in the LHS
 ```
Please no... If we can't have `auto (a, b) = call();` then we better not have it at all...
Why not allow both?
May 20
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 5/20/25 11:59, jmh530 wrote:
 On Tuesday, 20 May 2025 at 09:33:40 UTC, Dejan Lekic wrote:
 On Tuesday, 13 May 2025 at 09:04:07 UTC, Basile B. wrote:
 ```d
 (auto a, auto b) = call(); // two VarDeclExp in the LHS
 ```
Please no... If we can't have `auto (a, b) = call();` then we better not have it at all...
Why not allow both?
Both variants work with the design proposed in the DIP, but Basile's alternative proposal by default would allow at most one of these, which is what Dejan was objecting to.
May 20