On 6/2/25 21:48, Atila Neves wrote:
> On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:
>> This DIP proposes built-in tuple unpacking syntax for D. A sample of the proposed syntax:
>> ```d
>> import std.typecons : tuple;
>>
>> [...]
> 
> Why not a full tuple DIP?

Unpacking is the biggest tuple-related omission in D's current feature set, and we can make that work now by pulling the already existing implementation.

There is an incomplete proof of concept implementation that currently lowers to `std.typecons.Tuple` here: https://github.com/tgehr/dmd/tree/tuple-syntax

The goal is to make that either a built-in type with all bells and whistles or at the very least lower to a new struct in druntime instead.


Some more work is required for design and implementation of the full tuple DIP, for example:

- `opArgs`? (i.e., calling an n-ary function with a single n-tuple of its arguments). I have a design that I like where `void foo(int x,)` declares `foo` as unpacking a `1`-tuple argument analogous to how `(int x,) = t;` would unpack such a `1`-tuple, but this is a) a breaking change and b) probably somewhat controversial. It's also only partially implemented at the moment.

- static indexing and slicing operators for structs.

- it seems unpacking assignment is not so easy to implement in a clean way, particularly if tuple expressions are lowered early in semantic analysis (c.f. https://github.com/tgehr/dmd/pull/12 )

- `()` should be both a type and an expression and should be supported as an alias parameter as such

- reverse type inference like
  `(bool function(int), string delegate(bool)) t = (x=>!!x, x=>text(x));`
  is not implemented at all.

It's mostly a matter of me currently not being able to put in the time and energy required to pull off a full tuple DIP, but any help is of course appreciated. Meta and Nick have been stepping up to help get unpacking over the finish line.

On Thursday, 5 June 2025 at 18:10:30 UTC, Timon Gehr wrote:
> On 6/2/25 21:48, Atila Neves wrote:
>> [...]
>
> Unpacking is the biggest tuple-related omission in D's current feature set, and we can make that work now by pulling the already existing implementation.
>
> [...]

I just hope you relevant people can get some good discussion on this at dconf, and make some affirmative decision to implement it in 2025... (perhaps even with some breaking changes along the way). Good luck with a swift and good decision.