ceylon/ceylon-spec — Issue #81: Tuples
Author: gavinking
Created: 2011-12-01 18:21:06+00:00
State: open
Labels: request for feedback

I'm raising this issue here because it keeps coming up, and we need a permanent location to keep the discussion, instead of me having to re-explain my thinking on this issue every time. Nevertheless, this *is* an issue that we want to hear feedback on, even though I'm pretty sure I already know what the feedback will be.

Currently the #1 feature request for the language is support for tuples. I'm personally a skeptic, though I recognize that this is an argument I will likely lose. Let me explain why I'm a skeptic.

The thing is, almost every usecase people show for why tuples are sooo convenient, fall into one or more of the following possible categories:

* a union type is *much* more appropriate, or
* an intersection type or mixin inheritance is more appropriate, or
* it's anyway a tuple of length 2 (a `Pair`), or
* it's a 3-d coordinate, a tuple of length 3.

We don't need tuples to abstract over pairs. Indeed, we already have `Entry`, and the spec proposes a destructuring syntax for it. It would be very easy to slightly generalize `Entry` to `Pair`. Nor do we really need tuple support to represent coordinates in 3-dimensional space.

And a whole class of usecases for tuples, [example here](http://blog.nfnitloop.com/2011/03/scala-vs-java-anti-pattern.html), vanishes now we have union types.

Finally, when the usecase doesn't fit into one of these 3 categories, it is usually an attempt to work around the nominal type system and get a poor mans structural typing. Personally, I think creating a language like Ceylon based on structural typing with aliases rather than nominal typing would be a really interesting exercise, but that's not *this language*.

On the other hand, arguing against myself, as usual, there is one usecase that I have run into:

* access to data in a relational database, or some other kind of information system, with a "foreign" type system.

This usecase, in and of itself, might be sufficient to justify tuples, I'm not sure.

Finally, it's worth noting that because Ceylon has sequenced type parameters, representing tuples within our type system is actually really quite straightforward. What bothers me is not tuples themselves, but all the extra sytax sugar you need to introduce to make them actually useful:

* a nice way to construct them `(name, age, address)`,
* a nice way to write down their type `(String, Natural, Address)`, and
* destructuring syntax `value name, age, address = .....`.