On 13.01.2018 12:43, Jacob Carlborg wrote:
> On 2018-01-12 23:44, Timon Gehr wrote:
>> As promised [1], I have started setting up a DIP to improve tuple ergonomics in D:
> 
> Perhaps I don't have enough knowledge about the existing different types of tuples but Proposal 1 [1] says:
> 
> "We add the following syntactic sugar to unpack AliasSeq's"
> 
> But the example doesn't contain a single "AliasSeq", only "tuple".
> 
> [1] https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-1-unpacking-declarations 
> 
> 

Tuples are structs with alias this to a member AliasSeq, but I can add another example that uses the AliasSeq directly.

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
> [1] https://forum.dlang.org/post/or625h$2hns$1@digitalmars.com

Awesome!!! Thank you for the proposal! -- Ilya

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:
>
> [...]

how do we vote for / support this DIP?

https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-4-unpacking-assignments
```
(a, b) = t;
// shouldn't it be:
auto (a, b) = t;
```
?




On Sat, Jan 13, 2018 at 9:52 AM, Mengu via Digitalmars-d <digitalmars-d@puremagic.com> 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:
>>
>> [...]
>
>
> how do we vote for / support this DIP?

https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-6-placeholder-name-_

> Symbols with the name _ should not be inserted into the symbol table.
why not use `?` instead of `_` ?
no breaking change and should be unambiguous with (expr ? expr : expr) syntax




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 19:07, Timothee Cour wrote:
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-4-unpacking-assignments
> ```
> (a, b) = t;
> // shouldn't it be:
> auto (a, b) = t;
> ```
> ?
> 

No, but there was a mistake in the code that explains the confusion.
It should be:

(int, string) t = (1, "2");
int a;
string b;
(a, b) = t; // note: a and b exist already, now a==1, b=="2"

I have fixed it now. Proposal 4 is about allowing tuple literals of lvalues as the left hand side of an assignment.

On 13.01.2018 19:11, Timothee Cour wrote:
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md#proposal-6-placeholder-name-_
> 
>> Symbols with the name _ should not be inserted into the symbol table.
> why not use `?` instead of `_` ?
> no breaking change and should be unambiguous with (expr ? expr : expr) syntax
> 
> 

It's unambiguous but nonstandard and a bit noisy. Also, it's slightly harder to support in the parser (although that shouldn't be a big concern).

However, this proposal is independent of all the other ones, so in the end it is up to Walter and Andrei.

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
>
>
> 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


When I raised this feature for D, suggestions on the use of () instead of {} got me concerned. All languages that I know to have this feature (known as destructuring) use curly braces. Thats what kotlin and JavaScript (that I know have support) use. Let's not be Rust that goes with different syntax without any technical advantage. curly braces are more common (So to speak).

auto (name, email) = fetchUser();
   vs
auto {name, email} = fetchUser();

On Sat, 13 Jan 2018 19:43:48 +0000, aberba wrote:

> 
> When I raised this feature for D, suggestions on the use of () instead
> of {} got me concerned. All languages that I know to have this feature
> (known as destructuring) use curly braces. Thats what kotlin and
> JavaScript (that I know have support) use. Let's not be Rust that goes
> with different syntax without any technical advantage. curly braces are
> more common (So to speak).
> 
> auto (name, email) = fetchUser();
>     vs
> auto {name, email} = fetchUser();

Python and Pony use (). C++17 uses []. 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'm not sure I like the idea of ever reading `foo((a, b), c);`, but like templates, I'd get used to it.

On 13.01.2018 20:43, aberba wrote:
> 
> When I raised this feature for D, suggestions on the use of () instead of {} got me concerned. All languages that I know to have this feature (known as destructuring) use curly braces.

It seems that this is actually not the case.
Anyway, I'd suggest having a look at more languages.

> Thats what kotlin and JavaScript (that I know have support) use.

They actually do not.

https://kotlinlang.org/docs/reference/multi-declarations.html

I.e. Kotlin also uses parentheses. They do this because it is standard.


https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

In JavaScript, curly braces are used for object destructuring, not tuple destructuring. JavaScript does not have tuples, because without typing, they would be redundant with arrays. For array destructuring, JavaScript uses square brackets. This makes a lot of sense, as square brackets are also used to write array literals. Tuples are usually written using parentheses.

> Let's not be Rust that goes with different syntax without any technical advantage.

The syntax the DIP proposes is as close to standard as it gets.

(Also, the idea that Rust syntax has no technical advantage whatsoever over C syntax is ridiculous. Can't say I enjoy all of their choices though, e.g. using + for multiple trait bounds is atrocious.)

> curly braces are more common (So to speak).
> 

They really are not.

> auto (name, email) = fetchUser();
>     vs
> auto {name, email} = fetchUser();
>