April 04
On Tuesday, 1 April 2025 at 19:26:53 UTC, Timon Gehr wrote:
> - Unpacking does not yet support auto-expanding, for example:
>
>   (AliasSeq!(int. int) x, int y) = tuple(1, 2, 3);
>
>   does not work yet.

Why should this work ? From the type system point-of-view it's a bit like if you say that

```d
((int,int), int) a = (1,2,3);
```

has to work. You dont have to support that.
April 04

On Friday, 4 April 2025 at 12:25:03 UTC, Nick Treleaven wrote:

>

I built the branch and tried that sample and some variations, but they each get:

/home/nick/git/dmd/generated/linux/release/64/../../../../../phobos/std/json.d(144): Error: no property `Entry` for type `object.TypeInfo_AssociativeArray`
                JSONValue[string] unordered;
                                  ^
/home/nick/git/dmd/generated/linux/release/64/../../../../druntime/import/object.d(1289):        class `TypeInfo_AssociativeArray` defined here
class TypeInfo_AssociativeArray : TypeInfo
^

And:

core.exception.AssertError@src/dmd/typinf.d(112): Assertion failure

I'm not sure if it's something to do with my setup or not. My Phobos is recent git, probably that's why.

I was using import std;. Using single module imports (or avoiding std) works!

auto (x, y, z) = (1, 2, 3);

void main()
{
    import core.stdc.stdio;
    printf("%d %d %d\n", x,y,z);
    //import std.stdio;
    //writeln(x,y,z);
}

Uncommenting writeln causes a link error for me though:

Error: undefined reference to `pure nothrow bool core.internal.gc.blockmeta.__setArrayAllocLengthImpl(ref core.memory.BlkInfo_, ulong, bool, ulong, ulong)`
       referenced from `pure nothrow bool core.internal.array.utils.__setArrayAllocLength!(char).__setArrayAllocLength(ref core.memory.BlkInfo_, ulong, bool, ulong)`
April 04

On Tuesday, 1 April 2025 at 19:26:53 UTC, Timon Gehr wrote:

>

Assigning to a tuple literal seems to be a no-op ATM:

void main()
{
    int a,b;
    (a, b) = (4, 5);
    printf("%d %d\n", a,b); // 0 0

    auto t = (6, 7);
    printf("%d %d\n", t[0], t[1]); // 6 7

    (a, b) = t;
    printf("%d %d\n", a,b); // 0 0 still
}
April 04

On Friday, 4 April 2025 at 13:43:36 UTC, user1234 wrote:

>

On Tuesday, 1 April 2025 at 19:26:53 UTC, Timon Gehr wrote:

>
  • Unpacking does not yet support auto-expanding, for example:

    (AliasSeq!(int. int) x, int y) = tuple(1, 2, 3);

    does not work yet.

Why should this work ? From the type system point-of-view it's a bit like if you say that

((int,int), int) a = (1,2,3);

has to work. You dont have to support that.

Sorry for the noise, i see the thing now... AliasSeq!(int. int) is not a tuple, it's supposed to expand to two disctint VarDecls within the parent tuple.

April 04

On Friday, 4 April 2025 at 13:59:52 UTC, Nick Treleaven wrote:

>

Assigning to a tuple literal seems to be a no-op ATM:

void main()
{
    int a,b;
    (a, b) = (4, 5);

That line lowers to:

    tuple(a, b).opAssign(tuple(4, 5));

So it's assigning to a temporary tuple copy of a and b's data, rather than the fields by reference.

April 04

On Friday, 4 April 2025 at 13:46:45 UTC, Nick Treleaven wrote:

>

Using single module imports (or avoiding std) works!

Actually it requires import std.typecons; otherwise you get:

/home/nick/os/tupdip.d(6): Error: undefined identifier `std`
  auto (x, y, z) = (1, 2, 3);
                   ^

Probably that should be automatic.

April 04

On Friday, 4 April 2025 at 15:39:02 UTC, Nick Treleaven wrote:

>

Actually it requires import std.typecons; otherwise you get:

/home/nick/os/tupdip.d(6): Error: undefined identifier `std`
  auto (x, y, z) = (1, 2, 3);
                   ^

Probably that should be automatic.

https://github.com/tgehr/dmd/pull/1

I'll look at doing the same for tuple types.

April 04

On Friday, 4 April 2025 at 14:03:56 UTC, user1234 wrote:

>

On Friday, 4 April 2025 at 13:43:36 UTC, user1234 wrote:

>

On Tuesday, 1 April 2025 at 19:26:53 UTC, Timon Gehr wrote:

>
  • Unpacking does not yet support auto-expanding, for example:

    (AliasSeq!(int. int) x, int y) = tuple(1, 2, 3);

    does not work yet.

Why should this work ? From the type system point-of-view it's a bit like if you say that

((int,int), int) a = (1,2,3);

has to work. You dont have to support that.

Sorry for the noise, i see the thing now... AliasSeq!(int. int) is not a tuple, it's supposed to expand to two disctint VarDecls within the parent tuple.

You probably have to lower that to

alias __TempType = AliasSeq!(int,int);
__TempType x;
(x[0], x[1], int y) = tuple(1, 2, 3);

and put the three new things in a CommaExp. There might be problems because of the context tho, it's not a straight path, so some kinds of annoying flags might be required.

April 04
On 4/4/25 16:07, Nick Treleaven wrote:
> On Friday, 4 April 2025 at 13:59:52 UTC, Nick Treleaven wrote:
>> Assigning to a tuple literal seems to be a no-op ATM:
>> ```d
>> void main()
>> {
>>     int a,b;
>>     (a, b) = (4, 5);
> 
> That line lowers to:
> ```d
>      tuple(a, b).opAssign(tuple(4, 5));
> ```
> So it's assigning to a temporary tuple copy of a and b's data, rather than the fields by reference.

Yes, the tuple-syntax branch is less ready than the unpacking branch.
April 04
On 4/4/25 18:16, Nick Treleaven wrote:
> On Friday, 4 April 2025 at 15:39:02 UTC, Nick Treleaven wrote:
>> Actually it requires `import std.typecons;` otherwise you get:
>>
>> ```
>> /home/nick/os/tupdip.d(6): Error: undefined identifier `std`
>>   auto (x, y, z) = (1, 2, 3);
>>                    ^
>> ```
>> Probably that should be automatic.
> 
> https://github.com/tgehr/dmd/pull/1
> 
> I'll look at doing the same for tuple types.

Thanks! Though perhaps forwarding to `std.typecons.tuple` may not be what we end up doing in the end.