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
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.
as a comparison - in 3.7.0 (x = 1) went directly from an assignment (as in pre 3.7) to named tuple creation - i think there was some warning in 3.7-migration language mode that this would change?
Looking at Source Compatibility. - Yes, we can restart the one-element tuple SIP with the change of the semantics.
But in any case, this will be after target SLC, so we can look at Tupla apply/unapply and one-element changes independently.
The changes in the topic here seems much safer for now. Does anyone has any comments or doubts about it? I plan to raise it next week on the Scala Core team meeting.
the temporary import thing feels like it could get messy tho—like everyone would need to remember to add it during migration, and tooling would have to catch it too. is there a reason you can’t just deprecate (1,) first, let it warn for a release or two, then flip the switch? that seems simpler than having an import hanging around