DIP32: Uniform tuple syntax

[bearophile]

kenji hara:

> http://wiki.dlang.org/DIP32

Thank you Kenji for working on this :-)

Some comments on your proposal:

- - - - - - - - - - - -

> Use braces and commas. Inside tuple literal, ; never appears. 
> So it will not be confused with lambdas and ScopeStatements.<

This is true. On the other hand it's not too much hard to forget 
a ; or to not see it by mistake. So please let's think well about 
this important design decision.

- - - - - - - - - - - -

I presume this will be valid code:

auto tup = {10, "hi", 3.14};
assert(tup[0..2] == {10, "hi"});

- - - - - - - - - - - -

One handy tuple syntax in Haskell allows you to name both the 
items of a tuple and it whole:


void foo(t2@{int a, string b}) {
    // here a and b are tuple items and t2 is the whole tuple.
}
auto t1@{x, y} = {10, "hi"};
foo(t1);

- - - - - - - - - - - -

auto tup = {};  // zero-element tuple (Syntax meaning will be 
changed!)


Nullary tuples are not that useful in D. Scala doesn't even have 
a short literal for them.

So a longer syntax like this is acceptable:

auto tup = Tuple();

- - - - - - - - - - - -

This is nice, so we are merging tuple types with tuples, this 
will simplify D language:

// declare tuple value by using explicit tuple type
{int, string} tup = {1, "hi"};

  alias TL = {int, string[], double[string]};  // types


But one thing to remember in the document is that here T1 and T2 
are different, because your tuples do not auto-flatten as 
TypeTuples currently do:

alias T1 = {float, double, real};
alias T2 = {float, double, {real}};

- - - - - - - - - - - -

foreach (Float; {float, double, real}) { ... }

I think you meant to put a variable name there.

- - - - - - - - - - - -

     {1}         // one-element tuple

I presume this too will be accepted as 1-tuple:

     {1,}

- - - - - - - - - - - -

{c, $} = tup;   // Rewritten as: c = tup[0];

$ is used for array lengths, so it's not so good to overload it 
to mean "don't care" too.


Alternative syntaxes:

{c, $_} = tup;
{c, @} = tup;
{c, @_} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c, @~= tup;
etc.

- - - - - - - - - - - -

if (auto {1, y} = tup) {
     // If the first element of tup (tup[0]) is equal to 1,
     // y captures the second element of tup (tup[1]).
}


I suggest to leave that pattern matching plus conditional to a 
future refinement of tuple implementation (a second stage. And 
remove it from this first stage proposal. So I suggest to split 
your proposal in two successive proposals). It seems handy, but D 
programmers need some time to go there.

- - - - - - - - - - - -

switch (tup) {
     case {1, 2}:
     case {$, 2}:
     case {1, x}:    // capture tup[1] into 'x' when tup[0] == 1
     default:        // same as {...}
}


What's quite important here is the "final switch". D has to make 
sure you are considering all possible cases.

- - - - - - - - - - - -

I suggest to leave this to the second stage, and remove it from 
this proposal:

auto tup = {1, "hi", 3.14, [1,2,3]};
if (auto {1, "hi", ...} = tup) {}

- - - - - - - - - - - -

"will" is written badly:

// If the first element of coord is equal to 1 (== x), 'then' 
statement wil be evaluated.


- - - - - - - - - - - -

I think this is the third thing to leave to the second stage:


int x = 1;
if (auto {$x, y} = coord) { ... }

- - - - - - - - - - - -

This is nice:

if (auto {x, y} = coord[]) {}   // same, explicitly expands fields

- - - - - - - - - - - -

This is handy and it's vaguely present in Python3, but I suggest 
to leave this (4th thing) to the second stage:

if (auto {num, msg, ...} = tup) {}      // ok, `...` matches to 
zero-elements.

- - - - - - - - - - - -

Bye,
bearophile