February 20, 2018 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to JN | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to ixid | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Tuple DIP | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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?
|
Copyright © 1999-2021 by the D Language Foundation