SLC: Tuple apply/unapply

Proposal – add to the Tuple companion object apply and unapply for any number of arguments.
(Before, it was only for zero and one arguments.

PR: Add uniform Tuple.apply and Tuple.unapply by rssh · Pull Request #24874 · scala/scala3 · GitHub
(also chande REPL to print Tuple(x) instead (x,) for one element tuple )

See also previous discussion: Syntax for type tuple with one element

4 Likes

I fully support:

However, I think we should do the opposite of

(in other words, we should allow (x,) == Tuple(x), but that is better discussed in the other thread)

This was in the previous discussion: at first I thought so, wrote a SIP, but then discovered (see @lihaoyi comment in WIP: proposition for one-element tuple syntax by rssh · Pull Request #121 · scala/improvement-proposals · GitHub ), that

val t = (
  1,
)

works today, and the trailing comma is discarded, and this is read as (1).

To avoid difference between (1,) and (1,\n), I have withdrow SIP.
(therefore, there exists a two-phase process to disallow (1,), and then reintroduce it, as @bishabosha pointed out), but I think that a release with source-incompatible changes should be explicitly marked in some way.

what about changing the semantics (of syntax like (1,)) and simultaneously starting requiring temporary language import in a single new scala release to keep accepting syntax like (1,), but make it mean a tuple? that would make the new syntax immediately available in a new scala version, without waiting for deprecation of old semantics.