Tuple literal syntax + Tuple assignment

[bearophile]

In the two threads (that are a single thread) most of the things I've seen are bad/wrong.

I have discussed about Tuples several times in the D newsgroup and in Bugzilla. Please don't ignore all my work.

Before designing tuple syntax you must decide what the purpose of D tuples is. Then you have to solve the design problems, and avoid all (or most) corner cases. In this discussion it's useful to have a certain experience of languages that use tuples often, as Python and others.

Tuples have some purposes:
- Python, Go and other languages show that it's handy to allow functions to return multiple values, this means a tuple.
- A handy tuple unpacking is useful at the calling point of a function that returns multiple return values.
- Tuples are also useful as quick-and-dirty structs, to sort items in a different order, etc.

It's useful to use [] to access tuple items, to slice tuples, concat them. It's useful for tuples to have a good textual representation, to be comparable lexicographically and to be hashable.

Another design decision is if tuples have a nominative or structural type, this problem comes out in this bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=4128

In my opinion it's good for a built-in D tuple to be a structural type. This also means you are allowed to perform an == among two tuples of different length (the result is known statically to be always false). I assume that D tuples know their length at compile-time.


Another significant problem is about naming things, currently the situation is a mess:
http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
http://d.puremagic.com/issues/show_bug.cgi?id=4113
In the end I have suggested to name "record" the typecons tuples, and "tuple" the typetuples.


I have several bug reports and enhancement requests about tuples, please take them into account:

http://d.puremagic.com/issues/show_bug.cgi?id=4577
http://d.puremagic.com/issues/show_bug.cgi?id=4582
http://d.puremagic.com/issues/show_bug.cgi?id=4591
http://d.puremagic.com/issues/show_bug.cgi?id=4666
http://d.puremagic.com/issues/show_bug.cgi?id=4846


Walter:

> A lot of it foundered on what the syntax for tuple literals should be. The top
> of the list is simply enclosing them in ( ).

This is a bad idea. It has caused troubles in Python because of the singleton syntax (tuple with 1 item).

One solution is to use a special unambigous delimiter to denote tuples, like (a similar solution is used in the Fortress language):

(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
(|1, 2, 3, 4|)


Otherwise a good solution is to use a name:

record()
record(1)
record(1, 2)
record(1, 2, 3)
record(1, 2, 3, 4)

I prefer the record() solution, but the first solution too acceptable.


> Finally, I got to thinking, why not just make it a special case:
> 
>   ( ) == tuple
>   (a) == parenthesized expression

This is not acceptable. No special cases, please. D has already a ton of special cases.
Python solves this with the (1,) syntax, but it's not nice, it's error-prone, and it confuses newbies.


> If expr represents a tuple, we (Andrei and I) were thinking about the syntax:
> 
>      auto (a, b, c, d) = expr;

On this topic I have this enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4579


> The Lithpers among you will notice that this essentially provides a handy
> car,cdr shortcut for tuples and arrays:
> 
>      auto (car, cdr) = expr;

This is bad, it's not explicit enough. If you want to support this semantics then the syntax has to show what you mean. Python uses a * to denote "grab the whole tail". In D you may use something else, others have suggested tree points, this works with dynamic arrays too:

auto (car, cdr...) = expr;


Regarding field names for tuples, I have used Python and I like the optional names of D tuples (records). In some situations you don't need names, but in other situations field names are handy and help avoid bugs. In Python code that processes and uses tuples contains too many [0] [1] [2] etc that aren't readable and are bug-prone.

But a good management of such names asks for the names to not change the type of the tuple, this is why I talk about structural typing for records.

Bye,
bearophile