Thread overview
First Draft: Tuple Unpacking Syntax
3 days ago
Meta
OT: Tuple Syntax and Placeholders (Re: First Draft: Tuple Unpacking Syntax)
7 hours ago
Timon Gehr
23 hours ago
Walter Bright
8 hours ago
Timon Gehr
3 days ago

This DIP proposes built-in tuple unpacking syntax for D. A sample of the proposed syntax:

import std.typecons : tuple;

(int a, string b) = tuple(1, "2");
assert(a == 1);
assert(b == "2");

auto (a, b) = tuple(1, "2");
static assert(is(typeof(a) == int));
static assert(is(typeof(b) == string));

auto (a, immutable b, c) = tuple(1, "2", 3.0);
static assert(is(typeof(a) == int));
static assert(is(typeof(b) == immutable string));
static assert(is(typeof(c) == double));

The DIP is based on Timon Gehr's old DIP for tuple syntax in D (https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md), but is solely limited to support for unpacking; it is not a full tuple-syntax DIP. If the reception and general sentiment for this DIP are positive, further enhancements to add built-in tuple support to D may be proposed in the future.

Thanks to Timon and Nick Treleaven for doing the bulk of the implementation and conceptual work on this proposal. I mainly just kickstarted things and am facilitating the DIP process.

The DIP:
https://github.com/MetaLang/DIPs/blob/bf357d16b1bce65ba4ed95a08d146d4015eeb2d7/DIPs/1NNN-JH-TG-NT.md

2 days ago
Overall quite good, just a couple of tweaks I'd prefer to have to make everyone's lives easier (such as custom runtime writers).



Proposal 3: Built-in tuple types and literals

Why are you putting it into object.d?

Its big enough as it is, and these types can be copied wholesale.

Putting them in a dedicated module would be a much better choice.



Proposal 6: Placeholder name _

This is guaranteed to break code, its going to have to wait for an edition to execute. No need to do it in two stages then.

23 hours ago
This is a well written DIP. Congratulations!

The forward range tuple is pretty cool.

Let's move forward with this.

bearophile's example uses `_` as a placeholder, but I don't see it mentioned in the rest of the DIP?

For the example:
```
auto arr = [tuple(1, "2"), tuple(3, "4"), tuple(5, "6")];

foreach((x, y); arr) {
    writeln(x, " ", y); // "1 2\n3 4\n5 6"
}

foreach((int x, string y); arr) {
    writeln(x, " ", y);// "1 2\n3 4\n5 6"
}
```

shouldn't there be a trailing \n after the 6?
8 hours ago
On 7/27/25 08:31, Walter Bright wrote:
> This is a well written DIP. Congratulations!
> 
> The forward range tuple is pretty cool.
> 
> Let's move forward with this.
> 
> bearophile's example uses `_` as a placeholder, but I don't see it mentioned in the rest of the DIP?
> ...

He had used it as a placeholder by convention, but it's just a valid identifier. It would not be possible to use it for two distinct variables in the same scope.

I.e., you can do:

```d
int _ = 2;
```

But not:

```d
int _ = 3;
int _ = 4;
```

Which would work with a true placeholder.

> For the example:
> ```
> auto arr = [tuple(1, "2"), tuple(3, "4"), tuple(5, "6")];
> 
> foreach((x, y); arr) {
>      writeln(x, " ", y); // "1 2\n3 4\n5 6"
> }
> 
> foreach((int x, string y); arr) {
>      writeln(x, " ", y);// "1 2\n3 4\n5 6"
> }
> ```
> 
> shouldn't there be a trailing \n after the 6?

Yes.

7 hours ago
On 7/25/25 15:42, Richard (Rikki) Andrew Cattermole wrote:
> Overall quite good, just a couple of tweaks I'd prefer to have to make everyone's lives easier (such as custom runtime writers).
> ...

I think you were looking at the wrong document, seems you were reading my old draft that had a bigger scope. Neither of these features are proposed by the DIP.

That said:

> 
> 
> Proposal 3: Built-in tuple types and literals
> 
> Why are you putting it into object.d?
> 
> Its big enough as it is, and these types can be copied wholesale.
> 
> Putting them in a dedicated module would be a much better choice.
> ...
> 

Something like `core.internal.tuple` or similar will probably be better.

> 
> Proposal 6: Placeholder name _
> 
> This is guaranteed to break code, its going to have to wait for an edition to execute. No need to do it in two stages then.
> 

Yes. This is why this is not part of this DIP.
7 hours ago
You are so right, I looked at the wrong document.

In that case I'd like to point out:

1. The wording around ``ref`` and ``out`` could be improved. The behavior of each should be matching and it does seem to read as such, even if it isn't in the same paragraph.

2. Moving elements should be in DIP even if implementation doesn't support it. I don't think anything special needs to be done here. My understanding is the compiler should be seeing the VarDeclaration -> VarDeclaration assignment and handle it normally.