LLM's think we should have language tuples!

[Timon Gehr]

On 4/4/25 14:25, Nick Treleaven wrote:
> On Tuesday, 1 April 2025 at 19:26:53 UTC, Timon Gehr wrote:
>>  It is more or less ready (and OpenD already pulled the current 
>> state), but there are various small things to finish.
> 
> Good to hear.
> 
>> E.g.:
>>
>> - expanding a zero-element tuple does not work properly yet (in 
>> general, even unrelated to unpacking)
>>   https://github.com/dlang/dmd/issues/20842
>>   I though I would have time to maybe fix this, but got sidetracked 
>> last time I attempted to see it through.
>>
>> - Unpacking does not yet support auto-expanding, for example:
>>
>>   (AliasSeq!(int. int) x, int y) = tuple(1, 2, 3);
>>
>>   does not work yet.
> 
> 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 at 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 think I have seen similar things before with mismatched versions.

I think for testing that version of the branch I had used Phobos commit 
60034b56e2a036a66fa78cbc0ec0290956423684

You may also need to build Phobos with the same compiler and druntime 
you are using for tests. (Though I don't see how not doing that could 
cause the errors you are seeing above.)

Also: Are you sure you are not accidentally importing the system object.d?

>> - I need to write an extensive test suite and address anything it may 
>> catch.
>>
>> - I have to write the DIP and suffer through the bikeshedding on the 
>> forum.
>>
>> Of course, one way to continue would be to just write tests for what 
>> works and pull this (e.g., behind a -preview switch) and to allow 
>> anyone who can spend the time required to take over the polishing effort.
> 
> A `-preview` switch would be great. Then with the tests devs will at 
> least keep it up-to-date with master. I think people would be more 
> likely to work on it too, or at least file bugs.
> ...

Sounds good, I will work towards that with the unpacking branch.