February 20, 2018
On 20.02.2018 01:57, Timothee Cour wrote:
> On Mon, Feb 19, 2018 at 4:05 PM, Timon Gehr via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 20.02.2018 00:53, Timothee Cour wrote:
>>>
>> Sure! Also, this:
>>
>> void main(string[] args){
>>      enforce(args.length==5, "Invalid args");
>>      auto (infile, colname, repl, outfile) = args[1..5].unpack;
>>      // ...
>> }
> 
> 
> how does that latter example work?
> 

IFTI. unpack could have the following overload:

auto unpack(size_t n,T)(T[n] args){
    return mixin("tuple("~iota(n).map!(i=>text("args[",i,"]")).join(",")~")");
}
March 15, 2018
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
> auto (a, b) = (1, 2);

For the assignment and unpacking grammar why not adopt the more streamlined Go syntax?

auto a, b = 1, 2; // Creates two new variables with the values 1 and 2
auto c, d = 1, (2,3); // A normal variable and a tuple

This would seem a lot clearer than:

auto (a, b) = (1,2);
auto (c, d) = (1, (2,3));
March 15, 2018
On Wednesday, 17 January 2018 at 06:44:21 UTC, Timon Gehr wrote:
> It uses tuples because it uses zip. The code does not compile today, because the lambda I'm passing to "map" has two parameters:
>
> auto a = [1, 2, 4, 7, 2];
> auto b = [3, 5, 3, 2, 4];
>
> // auto c = zip(a, b).map!((x, y) => x + y); // error
>
> auto c = zip(a, b).map!(t => t[0] + t[1]); // ok

We could make lambdas consistent with proposal 5:

// Proposal 5: Unpacking function arguments
void foo((int x, int y), int z){
    writeln(x, " ", y, " ", z);
}

// lambda takes one tuple of two elements
alias f = ((x, y)) => x + y;
auto c = zip(a, b).map!f; // ok

Is there a better example as to why a tuple decaying to function arguments is worth having vs the language complication?
March 15, 2018
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:
>
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

I may be out of the loop here, but what is the actual usecase for tuples? What benefits does it bring? Isn't stuff like auto a, b = func() less clean than using structs, e.g. FuncResult ab = func() ?
March 15, 2018
On Thursday, 15 March 2018 at 14:07:12 UTC, JN 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:
>>
>> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
>
> I may be out of the loop here, but what is the actual usecase for tuples? What benefits does it bring? Isn't stuff like auto a, b = func() less clean than using structs, e.g. FuncResult ab = func() ?

For example you can have optional return-values.
And you don't introduce a dependency of the definition of a particular type.
Also you can write the elemets of the tuple direct into instance of a different type, without the need of creating a temporary.

That said, I am not sure if I would be willing to pay the complexity cost for it.
March 15, 2018
On Thursday, 15 March 2018 at 14:11:47 UTC, Stefan Koch wrote:
> On Thursday, 15 March 2018 at 14:07:12 UTC, JN 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:
>>>
>>> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
>>
>> I may be out of the loop here, but what is the actual usecase for tuples? What benefits does it bring? Isn't stuff like auto a, b = func() less clean than using structs, e.g. FuncResult ab = func() ?
>
> For example you can have optional return-values.
> And you don't introduce a dependency of the definition of a particular type.
> Also you can write the elemets of the tuple direct into instance of a different type, without the need of creating a temporary.
>
> That said, I am not sure if I would be willing to pay the complexity cost for it.

Tuples was by far the most missed language feature in the "State of D" survey:

https://rawgit.com/wilzbach/state-of-d/master/report.html#180373345

(50% of all respondents mentioned tuples as a language feature they miss in D.)
March 15, 2018
On 15.03.2018 11:45, ixid wrote:
> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>> auto (a, b) = (1, 2);
> 
> For the assignment and unpacking grammar why not adopt [...] Go syntax?
> ...

It does not fit in.

> auto a, b = 1, 2; // Creates two new variables with the values 1 and 2
> auto c, d = 1, (2,3); // A normal variable and a tuple
> ...

For this use case, there is already this:

auto a = 1, b = 2;
auto c = 1, d = (2, 3);


Under your proposal, this would now suddenly parse as:

auto a = ((1, b) = 2);
auto c = ((1, d) = (2, 3));

March 15, 2018
On 15.03.2018 14:42, Nick Treleaven wrote:
> On Wednesday, 17 January 2018 at 06:44:21 UTC, Timon Gehr wrote:
>> It uses tuples because it uses zip. The code does not compile today, because the lambda I'm passing to "map" has two parameters:
>>
>> auto a = [1, 2, 4, 7, 2];
>> auto b = [3, 5, 3, 2, 4];
>>
>> // auto c = zip(a, b).map!((x, y) => x + y); // error
>>
>> auto c = zip(a, b).map!(t => t[0] + t[1]); // ok
> 
> We could make lambdas consistent with proposal 5:
> ...

Good point. That's indeed the intention, but I didn't get around to updating the grammar section.

> ...
> // lambda takes one tuple of two elements
> alias f = ((x, y)) => x + y;
> auto c = zip(a, b).map!f; // ok
> 
> Is there a better example as to why a tuple decaying to function arguments is worth having vs the language complication?

Yes, but I don't think a better example is even needed. If you think ((x, y)) => x + y is tolerable, you are unlikely to be convinced by a better example.

There's also the point that it is not unreasonable to expect that it already works when reading https://dlang.org/spec/class.html#alias-this.
May 02, 2018
On 15.03.2018 17:14, Timon Gehr wrote:
>>>
>>
>> We could make lambdas consistent with proposal 5:
>> ...
> 
> Good point. That's indeed the intention, but I didn't get around to updating the grammar section.

Nevermind, it's already there, as the grammar shares "Parameters" between functions and function literals (as it should).
June 26, 2018
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?