The D Blog is Back -- A Tale of Tuples

[Timon Gehr]

On 4/13/26 11:38, Anton Pastukhov wrote:
> On Sunday, 12 April 2026 at 13:12:25 UTC, Mike Parker wrote:
>> I want to thank Jared Hanson for taking on a project that's long been 
>> on my TODO list. He has migrated the D Blog from the dlang.org server 
>> to GitHub Pages. It's a much simpler process to publish new blog posts 
>> than what we had before. It now lives at [blog.dlang.org](https:// 
>> blog.dlang.org/).
> 
> The new syntax is much appreciated, hope to see it released soon.
> 
> libxmoc, out of curiosity, what is half-baked in the current tuples 
> implementation?
> 
> 

A tuple is currently just:

```d
struct Tuple(T...) {
     T expand;
     alias this = expand;
}
```

Tuple!T tuple(T...)(T args) => Tuple!T(args);

`std.typecons.tuple` adds a bit more bells and whistles, but is still 
essentially just this. This is the structure that unpacking currently 
targets (in addition to free-standing sequences).

It would be more desirable to have `(a, b)` that feels first-class.

Something I have been chasing is allowing argument lists to be stored in 
an intermediate variable `f(a, (b, c))` ⇔ `auto t = (a, (b, c)); f(t);`

However, this is a bit tricky to achieve and unfortunately right now you 
would have to do:

```d
// (half-baked)
import std.typecons.tuple;
[tuple(1, 2), tuple(2, 3)].map!( ((a, b)) => a+b ).writeln;
```

Instead of
```d
// fully baked
[(1, 2), (2, 3)].map!((a, b) => a + b).writeln;
```

Ideally we also want to allow things like:

```d
(a, b) = (b, a); // swap
```

My original draft proposal is here: 
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

Proposal 1 is in the DIP, Proposal 2 was informally rejected by Walter 
(though he was more open to `opArgs` that is not based on extending the 
contexts in which `alias this` may expand, though I am not sure what 
exactly to propose, maybe breaking trailing commas in single-argument 
lists is not ideal, but everything else would be a bit ad-hoc), Proposal 
5 is partially in the DIP (just for function literals), Proposal 6 would 
be breaking, but I think generally useful, so maybe in an edition.

Some more considerations are here: 
https://forum.dlang.org/post/101smim$2b4h$1@digitalmars.com