Tuple Unpacking Syntax (page 3)

May 20

Re: Tuple Unpacking Syntax

Posted by jmh530
in reply to Meta

Permalink

jmh530

Posted in reply to Meta

Permalink

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:

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 Trealeven 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/tuple-unpacking-dip/DIPs/DIP1052.md

Let's say you have

auto (a, b) = tuple(1, "2");

and decide to change the "2" to 2, so you now have

auto (a, b) = tuple(1, 2);

And then you're, like well why do I need auto here, I know the types. So then you write

(int a, int b) = tuple(1, 2);

Ok. That's fine. But then I would wonder why this DIP doesn't allow the following syntax:

int (a, b) = tuple(1, 2);

Why would someone want this? You might say, why would someone want a tuple with all the types the same? Why not just use a static (or dynamic) array instead of a tuple? Well, if they started with a tuple, then they may not want to go back and change it. Less re-factoring. But if the unpacking syntax can work with tuples, then why not also have it work for arrays?

On 5/20/25 14:27, jmh530 wrote: > > Ok. That's fine. But then I would wonder why this DIP doesn't allow the following syntax: > ``` > int (a, b) = tuple(1, 2); > ``` a) With C-style conventions, `int (a, b)` would say: we declare that the expression `(a, b)` has type `int`, which is not what we are looking for. b) Grammar ambiguity. `T (a, b) = tuple(1, 2)` could just as well be read as `T(a,b).opAssign(tuple(1,2))`.

On Tuesday, 20 May 2025 at 19:29:34 UTC, Timon Gehr wrote:

On 5/20/25 14:27, jmh530 wrote:

Ok. That's fine. But then I would wonder why this DIP doesn't allow the following syntax:

int (a, b) = tuple(1, 2);

a) With C-style conventions, int (a, b) would say: we declare that the expression (a, b) has type int, which is not what we are looking for.

b) Grammar ambiguity. T (a, b) = tuple(1, 2) could just as well be read as T(a,b).opAssign(tuple(1,2)).

On a), the DMD compiler won't let you write int (a, b); It looks like what it is trying to do is to construct something (suggesting the issue is similar to what you describe in b)).

One potential solution would be that T(a, b) = tuple(1, 2) gets lowered to T(a,b).opAssign(tuple(1,2)), but T (a, b) = tuple(1, 2) gets lowered to T(a,b).opUnpack(tuple(1,2)). Potentially breaks code.

If you believe a) is an issue, does that make you cautious at all about allowing auto (a, b)? Now that I've thought about it, I wonder if people might potentially find that confusing.

Forums