On 13.01.2018 21:39, rjframe wrote:
> Python and Pony use (). C++17 uses [].

Any idea why C++17 went with [] ?

> Perhaps D should use <>? [not a
> serious question]
> 
> It was hard for me not to use angled brackets for templates when I started
> with D, but now it's second nature. I think you're right, familiarity with
> other languages is important, but it isn't everything.
> ...

I'd like to stress again that the proposed syntax is standard.

> I'm not sure I like the idea of ever reading `foo((a, b), c);`, but like
> templates, I'd get used to it.

It would actually be unsatisfying to have two distinct ways to group together a heterogeneous list (Tuples vs. function argument lists.)

foo((a, b), c);

auto args = ((a, b), c);
foo(args);

On 13.01.2018 21:49, Timon Gehr wrote:
> 
>> auto (name, email) = fetchUser();
>>     vs
>> auto {name, email} = fetchUser();
>>

BTW: What do you think each of those do?
I'd expect the following:

---
auto (name, email) = fetchUser();
=>
auto __tmp = fetchUser();
auto name = __tmp[0], email = __tmp[1];
---

---
auto {name, email} = fetchUser();
=>
auto __tmp = fetchUser();
auto name = __tmp.name, email = __tmp.email;
---

The DIP proposes only the first one of those features, and only for AliasSeq's or types that alias this to an AliasSeq (such as tuples).

On Sat, 13 Jan 2018 21:57:31 +0100, Timon Gehr wrote:

> On 13.01.2018 21:39, rjframe wrote:
>> Python and Pony use (). C++17 uses [].
> 
> Any idea why C++17 went with [] ?

I don't know; the paper[1] says it was due to "feedback from the EWG session in Jacksonville".

> 
> It would actually be unsatisfying to have two distinct ways to group together a heterogeneous list (Tuples vs. function argument lists.)
> 
> foo((a, b), c);
> 
> auto args = ((a, b), c);
> foo(args);


It makes sense; I just know I'm going to end up overlooking them while scanning code until I get used to it.



[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0217r3.html

On Saturday, 13 January 2018 at 20:57:31 UTC, Timon Gehr wrote:
> On 13.01.2018 21:39, rjframe wrote:
>> Python and Pony use (). C++17 uses [].
>
> Any idea why C++17 went with [] ?
>
>> Perhaps D should use <>? [not a
>> serious question]
>> 
>> It was hard for me not to use angled brackets for templates when I started
>> with D, but now it's second nature. I think you're right, familiarity with
>> other languages is important, but it isn't everything.
>> ...
>
> I'd like to stress again that the proposed syntax is standard.
>
>> I'm not sure I like the idea of ever reading `foo((a, b), c);`, but like
>> templates, I'd get used to it.
>
> It would actually be unsatisfying to have two distinct ways to group together a heterogeneous list (Tuples vs. function argument lists.)
>
> foo((a, b), c);
>
> auto args = ((a, b), c);
> foo(args);

Yeah. Consider the implications for UFCS: you'd want both (a, b).foo(c) and ((a, b), c).foo() to work.

On Sat, 13 Jan 2018 22:10:39 +0000, rjframe wrote:

> On Sat, 13 Jan 2018 21:57:31 +0100, Timon Gehr wrote:
> 
>> On 13.01.2018 21:39, rjframe wrote:
>>> Python and Pony use (). C++17 uses [].
>> 
>> Any idea why C++17 went with [] ?
> 
> I don't know; the paper[1] says it was due to "feedback from the EWG session in Jacksonville".
> 

Not really tuples; but integrated with structs with tuple-like syntax.

On Saturday, 13 January 2018 at 21:05:27 UTC, Timon Gehr wrote:
> On 13.01.2018 21:49, Timon Gehr wrote:
>> 
>>> auto (name, email) = fetchUser();
>>>     vs
>>> auto {name, email} = fetchUser();
>>>
>
> BTW: What do you think each of those do?
> I'd expect the following:
>
> ---
> auto (name, email) = fetchUser();
> =>
> auto __tmp = fetchUser();
> auto name = __tmp[0], email = __tmp[1];
> ---
>
> ---
> auto {name, email} = fetchUser();
> =>
> auto __tmp = fetchUser();
> auto name = __tmp.name, email = __tmp.email;
> ---
>
> The DIP proposes only the first one of those features, and only for AliasSeq's or types that alias this to an AliasSeq (such as tuples).

How about this syntax for getting a tuple of fields:

---
auto (name, email) = fetchUser().(name, email);
---

it would also solve a long-standing issue of passing runtime optional arguments along with variadic templates, eg:

current:
```
# current: bad, causes template bloat (1 template per call site)
void log(string file=__FILE__, int line=__LINE__, T...)(T a);
# usage:
log(1, "foo");

# with this DIP
void log(T...)(T a, string file=__FILE__, int line=__LINE__);
log((1, "foo"));
```

still not ideal as syntax is not as nice, but at least it removes template bloat


On Fri, Jan 12, 2018 at 2:44 PM, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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
>
>
> This DIP aims to make code like the following valid D:
>
> ---
> auto (a, b) = (1, 2);
> (int a, int b) = (1, 2);
> ---
>
> ---
> foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
> {
>     writeln(sum, " ", diff);
> }
> /+ prints:
> 3 -1
> 7 1
> +/
> ---
>
> Before going ahead with it, I'd like some preliminary community input:
>
> - I'm not yet completely satisfied with the DIP.
>   (See section "Limitations".)
>   Please let me know suggestions or further concerns you might have.
>
>
> - There are good example use cases missing. While I'm confident I could
>   invent a few of them given a little time, I thought maybe I can
>   expedite the process and make the point more convincingly by asking
>   for use cases you encountered in your own code. The DIP already
>   contains an example due to bearophile.
>
>
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com

the DIP says this replace std.typecons.TypeTuple however no mention is made of named arguments, so I don't see how they could be a replacement (nor how would that allow for a migration path) without mentioning a word on this, eg:

what would be the equivalent of this ?
` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `

On Fri, Jan 12, 2018 at 2:44 PM, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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
>
>
> This DIP aims to make code like the following valid D:
>
> ---
> auto (a, b) = (1, 2);
> (int a, int b) = (1, 2);
> ---
>
> ---
> foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
> {
>     writeln(sum, " ", diff);
> }
> /+ prints:
> 3 -1
> 7 1
> +/
> ---
>
> Before going ahead with it, I'd like some preliminary community input:
>
> - I'm not yet completely satisfied with the DIP.
>   (See section "Limitations".)
>   Please let me know suggestions or further concerns you might have.
>
>
> - There are good example use cases missing. While I'm confident I could
>   invent a few of them given a little time, I thought maybe I can
>   expedite the process and make the point more convincingly by asking
>   for use cases you encountered in your own code. The DIP already
>   contains an example due to bearophile.
>
>
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com

On 13.01.2018 23:57, Timothee Cour wrote:
> the DIP says this replace std.typecons.TypeTuple however no mention is
> made of named arguments, so I don't see how they could be a
> replacement (nor how would that allow for a migration path) without
> mentioning a word on this, eg:
> 
> what would be the equivalent of this ?
> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `

It would continue to work the same way.

I did consider adding a proposal for built-in named tuple syntax:

writeln((x: 2, y: 3, z: 4).y);

(int a, double b) t = (a: 1, b: 2.0);
int x = t.a;
double y = t.b;

But I decided against it to keep the DIP focused, and because of potential future-proofing hazards related to named arguments. (For Phobos tuples, name mismatches are simply ignored when converting one named tuple into another, which I'm not sure is the best possible behavior, but the goal of this DIP is not to fight this design.)

some people have suggested using `{a, b}` instead of `(a,b)` ; this
would not work because of ambiguity, eg:
`auto fun(){ return {}; }`
already has a meaning, so the empty tuple would not work.
so `()` is indeed better.

On Fri, Jan 12, 2018 at 2:44 PM, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> 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
>
>
> This DIP aims to make code like the following valid D:
>
> ---
> auto (a, b) = (1, 2);
> (int a, int b) = (1, 2);
> ---
>
> ---
> foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
> {
>     writeln(sum, " ", diff);
> }
> /+ prints:
> 3 -1
> 7 1
> +/
> ---
>
> Before going ahead with it, I'd like some preliminary community input:
>
> - I'm not yet completely satisfied with the DIP.
>   (See section "Limitations".)
>   Please let me know suggestions or further concerns you might have.
>
>
> - There are good example use cases missing. While I'm confident I could
>   invent a few of them given a little time, I thought maybe I can
>   expedite the process and make the point more convincingly by asking
>   for use cases you encountered in your own code. The DIP already
>   contains an example due to bearophile.
>
>
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com