On Friday, 16 May 2025 at 06:08:41 UTC, Timon Gehr wrote:

import std.typecons;

void main()@nogc{
    (int a, float[3] b, string c) = tuple(1, [0.1F, 0.2F, 0.3F], "2"); // compile error
}

The next logical step after this DIP is to enable initialization of a tuple with a struct literal:

(int a, float[3] b, string c) = { 1, [0.1F, 0.2F, 0.3F], "2" };

On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

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));

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 Tuesday, 20 May 2025 at 19:29:34 UTC, Timon Gehr wrote:

int (a, b) = 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.

On Tuesday, 20 May 2025 at 07:09:55 UTC, Ogion wrote:

(int a, float[3] b, string c) = { 1, [0.1F, 0.2F, 0.3F], "2" };

Firstly, from the left-hand side, that is not tuple initialization. It is unpacking into declarations. Maybe you meant to have an identifier before the = token?

Secondly, for tuple initialization from a literal, the right hand-side IMO would naturally be a tuple literal. Mentioned in (but not proposed by) the DIP:

auto t = (1, 2); // tuple literal

Also conceptually a tuple is not a struct. Unpacking a struct's fields implicitly is not supported by this DIP (and I don't think it should be as it complicates/limits future options).

On Tuesday, 13 May 2025 at 03:23:14 UTC, Meta wrote:

For the record, Meta added an example with unpacking syntax for comparison:
https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md#rationale

On Monday, 2 June 2025 at 12:12:49 UTC, Nick Treleaven wrote:

Yeah, I had seen that. Nice improvement to the DIP.

On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

import std.typecons : tuple;

[...]

Why not a full tuple DIP?