RFC: 2 enhancement DIPs that need feedback

3 days ago

Meta

3 days ago

Basile B.

1 day ago

Timon Gehr

3 hours ago

Basile B.

3 days ago

Re: RFC: 2 enhancement DIPs that need feedback

Posted by Basile B.
in reply to Meta

Permalink

Basile B.

Posted in reply to Meta

Permalink

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.

(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:

printf("for the %dnth time\n", static int count++);

Yeah that kind of things work when you have "variable declaration" as expression.

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.

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.

Forums