On Tuesday, 26 June 2018 at 09:55:10 UTC, Francesco Mecca wrote:
> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>>
>> [...]
>
> What is the status of the DIP? Is it ready to be proposed and dicussed?

Look that the current DIP, it is still in the todo phrase.

On 26.06.2018 11:55, Francesco Mecca wrote:
> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>>
>> [...]
> 
> What is the status of the DIP? Is it ready to be proposed and dicussed?

I still need to incorporate all the feedback from this thread. Also, I have started an implementation, and ideally I'd like to have it finished by the time the DIP is discussed. Unfortunately I am rather busy with work at the moment.

On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote:
> On 26.06.2018 11:55, Francesco Mecca wrote:
>> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>>>
>>> [...]
>> 
>> What is the status of the DIP? Is it ready to be proposed and dicussed?
>
> I still need to incorporate all the feedback from this thread. Also, I have started an implementation, and ideally I'd like to have it finished by the time the DIP is discussed. Unfortunately I am rather busy with work at the moment.

Is there any way we can help on this?

On Tuesday, 3 July 2018 at 16:11:05 UTC, 12345swordy wrote:
> On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote:
>> On 26.06.2018 11:55, Francesco Mecca wrote:
>>> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>>>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>>>>
>>>> [...]
>>> 
>>> What is the status of the DIP? Is it ready to be proposed and dicussed?
>>
>> I still need to incorporate all the feedback from this thread. Also, I have started an implementation, and ideally I'd like to have it finished by the time the DIP is discussed. Unfortunately I am rather busy with work at the moment.
>
> Is there any way we can help on this?

*Bump* I want this. I am very tempted to start my own dip on this and finish it.

On 19.09.2018 23:14, 12345swordy wrote:
> On Tuesday, 3 July 2018 at 16:11:05 UTC, 12345swordy wrote:
>> On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote:
>>> On 26.06.2018 11:55, Francesco Mecca wrote:
>>>> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>>>>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
>>>>>
>>>>> [...]
>>>>
>>>> What is the status of the DIP? Is it ready to be proposed and dicussed?
>>>
>>> I still need to incorporate all the feedback from this thread. Also, I have started an implementation, and ideally I'd like to have it finished by the time the DIP is discussed. Unfortunately I am rather busy with work at the moment.
>>
>> Is there any way we can help on this?
> 
> *Bump* I want this.

So do I, but I need to get a quiet weekend or so to finish this.

> I am very tempted to start my own dip on this and finish it.

Here's the current state of my implementation in DMD:
https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax

It has no tests yet, but basically, with those changes, you can write tuple literals `(1, 2.0, "3")`, you can unpack tuples using `auto (a, b) = t;` or `(int a, string b) = t;`, and tuples can be expanded using alias this on function calls, so you can now write things like `zip([1,2,3],[4,5,6]).map!((a,b)=>a+b)`.

The implementation is still missing built-in syntax for tuple types, tuple assignments, and tuple unpacking within function argument lists and foreach loops.

On Saturday, 13 January 2018 at 18:28:55 UTC, Timon Gehr wrote:
> However, this proposal is independent of all the other ones, so in the end it is up to Walter and Andrei.

Have there been any discussions regarding the semantics of _?

struct G { ~this() { writeln("destruct"); } }
void main() {
    auto _ = G();
    writeln("here");
}

The DIP currently says this should print first "here" and then "destruct".

However, as you cannot access the variable later, you most often want to discard the data right away, i.e. print first "destruct" and then "here".

I personally find the second interpretation more useful.

On Wednesday, 19 September 2018 at 21:48:40 UTC, Timon Gehr wrote:
> On 19.09.2018 23:14, 12345swordy wrote:
>> On Tuesday, 3 July 2018 at 16:11:05 UTC, 12345swordy wrote:
>>> On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote:
>>>> [...]
>>>
>>> Is there any way we can help on this?
>> 
>> *Bump* I want this.
>
> So do I, but I need to get a quiet weekend or so to finish this.
>
>> I am very tempted to start my own dip on this and finish it.
>
> Here's the current state of my implementation in DMD:
> https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax
>
> It has no tests yet, but basically, with those changes, you can write tuple literals `(1, 2.0, "3")`, you can unpack tuples using `auto (a, b) = t;` or `(int a, string b) = t;`, and tuples can be expanded using alias this on function calls, so you can now write things like `zip([1,2,3],[4,5,6]).map!((a,b)=>a+b)`.
>
> The implementation is still missing built-in syntax for tuple types, tuple assignments, and tuple unpacking within function argument lists and foreach loops.

I was referring to the DIP. I am not familiar with the dmd compiler itself to create an implementation. Regardless I think you should finish you DIP and submit it as the process is going to take a very long time.

On Wednesday, 19 September 2018 at 21:48:40 UTC, Timon Gehr wrote:
> So do I, but I need to get a quiet weekend or so to finish this.
>
>> I am very tempted to start my own dip on this and finish it.
>
> Here's the current state of my implementation in DMD:
> https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax
>
> It has no tests yet, but basically, with those changes, you can write tuple literals `(1, 2.0, "3")`, you can unpack tuples using `auto (a, b) = t;` or `(int a, string b) = t;`, and tuples can be expanded using alias this on function calls, so you can now write things like `zip([1,2,3],[4,5,6]).map!((a,b)=>a+b)`.
>
> The implementation is still missing built-in syntax for tuple types, tuple assignments, and tuple unpacking within function argument lists and foreach loops.

Hey Timon, any progress on this? I've been excitedly wanting this tuple syntax since your DIP.

On 20.09.18 19:08, Guillaume Boucher wrote:
> On Saturday, 13 January 2018 at 18:28:55 UTC, Timon Gehr wrote:
>> However, this proposal is independent of all the other ones, so in the end it is up to Walter and Andrei.
> 
> Have there been any discussions regarding the semantics of _?
> 
> struct G { ~this() { writeln("destruct"); } }
> void main() {
>      auto _ = G();
>      writeln("here");
> }
> 
> The DIP currently says this should print first "here" and then "destruct".
> 
> However, as you cannot access the variable later, you most often want to discard the data right away, i.e. print first "destruct" and then "here".
> 
> I personally find the second interpretation more useful.
> 

This has not been discussed, but I agree it should be addressed somehow. The main issue is that right now "_" is a valid identifier.

On Monday, 3 June 2019 at 17:43:36 UTC, Timon Gehr wrote:
> On 20.09.18 19:08, Guillaume Boucher wrote:
>> On Saturday, 13 January 2018 at 18:28:55 UTC, Timon Gehr wrote:
>>> However, this proposal is independent of all the other ones, so in the end it is up to Walter and Andrei.
>> 
>> Have there been any discussions regarding the semantics of _?
>> 
>> struct G { ~this() { writeln("destruct"); } }
>> void main() {
>>      auto _ = G();
>>      writeln("here");
>> }
>> 
>> The DIP currently says this should print first "here" and then "destruct".
>> 
>> However, as you cannot access the variable later, you most often want to discard the data right away, i.e. print first "destruct" and then "here".
>> 
>> I personally find the second interpretation more useful.
>> 
>
> This has not been discussed, but I agree it should be addressed somehow. The main issue is that right now "_" is a valid identifier.

Not sure what the use case is for this, but if you don't need the value of the variable, assuming from a function or otherwise. You can just not assign it to anything.

struct G { ~this() { writeln("destruct"); } }
void main() {
    G();  // prints "destruct" before "here"
    writeln("here");
}

definitely don't like the idea of changing how scope works. I'd rather not the compiler choose to decide whether it does something one way or another like that.