RFC: 2 enhancement DIPs that need feedback

[Timon Gehr]

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.