RFC: 2 enhancement DIPs that need feedback

[Timon Gehr]

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.