www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Tuple Unpacking Syntax

reply Meta <jared771 gmail.com> writes:
This DIP proposes built-in tuple unpacking syntax for D. A sample 
of the proposed syntax:
```d
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
May 12
next sibling parent Meta <jared771 gmail.com> writes:
Apologies to Nick _Treleaven_ as I misspelled his name in my 
post; unfortunately, it can't be edited.
May 12
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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:


Note that this has been implemented and shipped in OpenD for a 
long time, many months. Your example works with the opend 
compiler right now; https://opendlang.org/start.html
May 12
parent reply Meta <jared771 gmail.com> writes:
On Monday, 12 May 2025 at 23:35:06 UTC, Adam D. Ruppe 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:


 Note that this has been implemented and shipped in OpenD for a 
 long time, many months. Your example works with the opend 
 compiler right now; https://opendlang.org/start.html


Very nice, I didn't know that. Is that using Timon's 
implementation?
May 12
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 12 May 2025 at 23:36:26 UTC, Meta wrote:

 Very nice, I didn't know that. Is that using Timon's 
 implementation?


Yes, he helped prepare it and we merged as soon as it was ready. 
Caused virtually zero breakage, so easy addition.
May 12
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
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;

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


Make overflowing assignments landmines rather then errors?

```d
auto foo(T)(T t){
   auto (a,b,c)=t;
   static if(T.length>2){
     return c;
   } else {
     return a;
}}
unittest{
   assert(foo(tuple(1,'b',"c"))=="c");
   assert(foo(tuple(1))==1);
}
auto bar(T)(T t){
   auto (a,b,c)=t;
   return c;
}
unittest{
   assert(foo(tuple(1,'b',"c"))=="c");
   assert(foo(tuple(1))==1);//fails `Error: tuple!int was split 
into 3 fields but only has 1, then `c` used on line 15 in 
bar!(tuple!int)
}
```
May 12
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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;

 (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 
 (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


In your rationale, you provide an example of how it works 
currently. You might show how it works with the DIP as well as a 
contrast.

Am I right that any function that returns a tuple can use it like
‘auto (a, b) = foo();’
Because that would be nice
May 12
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 13 May 2025 at 00:01:41 UTC, jmh530 wrote:

 In your rationale, you provide an example of how it works 
 currently. You might show how it works with the DIP as well as 
 a contrast.


Thanks, that's a great idea.


 Am I right that any function that returns a tuple can use it 
 like
 ‘auto (a, b) = foo();’
 Because that would be nice


Yup, that's right.
May 12
parent reply Nick Treleaven <nick geany.org> writes:
On Tuesday, 13 May 2025 at 03:23:14 UTC, Meta wrote:

 On Tuesday, 13 May 2025 at 00:01:41 UTC, jmh530 wrote:

 In your rationale, you provide an example of how it works 
 currently. You might show how it works with the DIP as well as 
 a contrast.


 Thanks, that's a great idea.


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
Jun 02
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 2 June 2025 at 12:12:49 UTC, Nick Treleaven wrote:

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

 On Tuesday, 13 May 2025 at 00:01:41 UTC, jmh530 wrote:

 In your rationale, you provide an example of how it works 
 currently. You might show how it works with the DIP as well 
 as a contrast.


 Thanks, that's a great idea.


 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


Yeah, I had seen that. Nice improvement to the DIP.
Jun 02
prev sibling next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


Awesome DIP!
To not have a built-in tuples in the lang is a shame!

Just to clarify, will the static arrays gonna work?
```d
(int a, float[3] b, string c) = tuple(1, 0.1, 0.2, 0.3, "2");
```
May 13
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 13 May 2025 at 07:25:06 UTC, Sergey wrote:

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

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


 Awesome DIP!
 To not have a built-in tuples in the lang is a shame!

 Just to clarify, will the static arrays gonna work?
 ```d
 (int a, float[3] b, string c) = tuple(1, 0.1, 0.2, 0.3, "2");
 ```


I'm pretty sure that works, except it should be [0.1, 0.2, 0.3].
May 13
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/13/25 22:19, Meta wrote:

 On Tuesday, 13 May 2025 at 07:25:06 UTC, Sergey wrote:

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

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/ 
 DIP1052.md


 Awesome DIP!
 To not have a built-in tuples in the lang is a shame!

 Just to clarify, will the static arrays gonna work?
 ```d
 (int a, float[3] b, string c) = tuple(1, 0.1, 0.2, 0.3, "2");
 ```


 
 I'm pretty sure that works, except it should be [0.1, 0.2, 0.3].


Has to be `[0.1, 0.2, 0.3].staticArray` actually, as there is no reverse 
type inference on IFTI.

In the future perhaps constructs like `(int a, float[3] b..., string c) 
= tuple(1, 0.1, 0.2, 0.3, "2");` can be added, but this is not part of 
this DIP.
May 14
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 May 2025 at 17:00:02 UTC, Timon Gehr wrote:

 On 5/13/25 22:19, Meta wrote:

 On Tuesday, 13 May 2025 at 07:25:06 UTC, Sergey wrote:

 Just to clarify, will the static arrays gonna work?
 ```d
 (int a, float[3] b, string c) = tuple(1, 0.1, 0.2, 0.3, "2");
 ```


 
 I'm pretty sure that works, except it should be [0.1, 0.2, 
 0.3].


 Has to be `[0.1, 0.2, 0.3].staticArray` actually, as there is 
 no reverse type inference on IFTI.


Either of these seem to work with the unpacking branch:
```d
(int a, float[3] b, string c) = tuple(1, [0.1F, 0.2F, 0.3F], "2");
(int a, double[3] b, string c) = tuple(1, [0.1, 0.2, 0.3], "2");
```
May 15
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/15/25 17:32, Nick Treleaven wrote:

 On Wednesday, 14 May 2025 at 17:00:02 UTC, Timon Gehr wrote:

 On 5/13/25 22:19, Meta wrote:

 On Tuesday, 13 May 2025 at 07:25:06 UTC, Sergey wrote:

 Just to clarify, will the static arrays gonna work?
 ```d
 (int a, float[3] b, string c) = tuple(1, 0.1, 0.2, 0.3, "2");
 ```


 I'm pretty sure that works, except it should be [0.1, 0.2, 0.3].


 Has to be `[0.1, 0.2, 0.3].staticArray` actually, as there is no 
 reverse type inference on IFTI.


 
 Either of these seem to work with the unpacking branch:
 ```d
 (int a, float[3] b, string c) = tuple(1, [0.1F, 0.2F, 0.3F], "2");
 (int a, double[3] b, string c) = tuple(1, [0.1, 0.2, 0.3], "2");
 ```
 


You are correct. I did not take into account that this works:

```d
void main(){
     int[] x=[1,2,3];
     int[3] y=x;
}
```

(I would actually prefer if this did not work.)


It is not a great way to do it:

```d
import std.typecons;

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

```d
import std.typecons;

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

Compare to:

```d
import std.typecons, std.array;

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

```

```d
import std.typecons, std.array;

void main() nogc{
	(int a, float[3] b, string c) = tuple(1, [0.1F, 0.2F, 0.3F, 
0.4F].staticArray, "2"); // compile error
}
```
May 15
parent reply Ogion <ogion.art gmail.com> writes:
On Friday, 16 May 2025 at 06:08:41 UTC, Timon Gehr wrote:

 It is not a great way to do it:

 ```d
 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:

```d
(int a, float[3] b, string c) = { 1, [0.1F, 0.2F, 0.3F], "2" };
```
May 20
parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 20 May 2025 at 07:09:55 UTC, Ogion wrote:

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

 ```d
 (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:

```d
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).
Jun 02
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

 [snip]

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


Typo in one of the headers for the "Grammar Changes" section:
"Proposal 5 (Unpacking function arguments)"
May 14
parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 May 2025 at 17:45:12 UTC, jmh530 wrote:

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

 [snip]

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


 Typo in one of the headers for the "Grammar Changes" section:
 "Proposal 5 (Unpacking function arguments)"


Thanks, PR:
https://github.com/MetaLang/DIPs/pull/17
May 15
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

 [snip]

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


If D adds built-in tuples in the future, would `.tupleof` be part 
of the language, or remain a library function?

I ask because (in the limitations section) it says you can use 
that with static arrays or aggregates. I guess I'm wondering if 
it would be possible to check if `.tupleof` works for a given 
type and then implicitly call it if someone can be assumed to 
wanting an unpacked version of these types.
May 14
next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 14 May 2025 at 18:09:11 UTC, jmh530 wrote:

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

 [snip]

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


 If D adds built-in tuples in the future, would `.tupleof` be 
 part of the language, or remain a library function?

 I ask because (in the limitations section) it says you can use 
 that with static arrays or aggregates. I guess I'm wondering if 
 it would be possible to check if `.tupleof` works for a given 
 type and then implicitly call it if someone can be assumed to 
 wanting an unpacked version of these types.


Funny you should mention that. I suggested the exact same thing 
to Timon, but what you are asking for is more complicated than it 
appears. I don't think .tupleof will be going anywhere, 
regardless of what happens with built-in tuples.
May 14
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/14/25 20:09, jmh530 wrote:

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

 [snip]

 The DIP:
 https://github.com/MetaLang/DIPs/blob/tuple-unpacking-dip/DIPs/DIP1052.md


 
 If D adds built-in tuples in the future, would `.tupleof` be part of the 
 language, or remain a library function?
 
 I ask because (in the limitations section) it says you can use that with 
 static arrays or aggregates. I guess I'm wondering if it would be 
 possible to check if `.tupleof` works for a given type and then 
 implicitly call it if someone can be assumed to wanting an unpacked 
 version of these types.


`.tupleof` in general is a low-level primitive that gives you a built-in 
auto-expanding sequence of all fields, including private ones. I don't 
think it is a good idea to call it implicitly for all types. For static 
arrays I think it would be defensible.

In general, in the future we may want to e.g. add something like 
`opUnpack`. However, note that it is possible to instead create a member 
function that returns a tuple supported by unpacking, so this is just a 
minor convenience (assuming the most obvious design).

One issue is unpacking by reference. In principle it should be possible 
to do that too, but DMD will not currently allow it due to this 
arbitrary limitation/bug: https://github.com/dlang/dmd/issues/21296
May 14
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 15 May 2025 at 02:17:15 UTC, Timon Gehr wrote:

 [snip]

 `.tupleof` in general is a low-level primitive that gives you a 
 built-in auto-expanding sequence of all fields, including 
 private ones. I don't think it is a good idea to call it 
 implicitly for all types. For static arrays I think it would be 
 defensible.

 In general, in the future we may want to e.g. add something 
 like `opUnpack`. However, note that it is possible to instead 
 create a member function that returns a tuple supported by 
 unpacking, so this is just a minor convenience (assuming the 
 most obvious design).
 [snip]


In the back of my head I recall people complaining about some 
built-in features (I think related to dynamic or associated 
arrays) have some special behavior that we can't take advantage 
of in user-defined types.

But probably worthwhile to add this DIP first and then think 
about `opUnpack` in the future.
May 15
prev sibling next sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 12 May 2025 at 23:01:54 UTC, Meta wrote:

 Thanks to Timon and Nick Trealeven for doing the bulk of the 
 implementation and conceptual work on this proposal.


The hard work was all Timon's ;-)
May 15
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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;

 (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?
May 20
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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))`.
May 20
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
May 21
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 5/21/25 18:34, jmh530 wrote:

 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.
 ...


This is not what it would lower to, a method call cannot declare free 
variables in the receiver.

If you want to accept an explicit type, you have to do it in two steps:

```d
Tuple!(int, int) t = foo();
auto (a, b) = t;
```

It does not really make sense to name a type for `(a, b)`, at least not 
without support for tuple type syntax.


 If you believe a) is an issue, does that make you cautious at all about 
 allowing `auto (a, b)`?


I don't see how that would be an issue for allowing `auto (a, b) =`. 
`auto` is not a placeholder for a type, it is a storage class, like 
`scope` or `immutable`.


 Now that I've thought about it, I wonder if 
 people might potentially find that confusing.



`(int, int) (a, b) = (1, 2);` does not work. It's pretty much the same 
thing and I think it makes sense.
Jun 01
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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?
Jun 02
next sibling parent Meta <jared771 gmail.com> writes:
On Monday, 2 June 2025 at 19:48:07 UTC, 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?


I discussed it with Timon and Nick, but we decided to limit the 
scope to unpacking, because the other stuff can be added down the 
line, and doing it this way keeps the DIP much simpler.
Jun 02
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 05
next sibling parent M. M. <matus email.cz> writes:
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.
Jun 05
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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.

 [...]


Ok, thanks.
Jun 12