This is a minor syntax corner case. A comma is required to construct a tuple from a single expression except for (x...)
, which is equivalent to (x...,)
. There is even a special case for this in the parser.
This doesn't matter so much, but there are cases where it would be nice to use parentheses just to affect the precedence of x...
. For example, 1 + xs...
doesn't work, because +
has higher precedence than ...
. (AFAICT, this is to allow 1:n...
to work, and :
has lower precedence than +
.) If we were fully consistent about requiring the comma to make a tuple, then 1 + (xs...)
could be used to splat into general infix calls.
Alternatively (or in addition), we could decide that 1:n...
is not important, and give ...
higher precedence, which would better match other unary and postfix operators.
I'm in favor of requiring the comma, unless that would also make the comma required in call expressions.
unless that would also make the comma required in call expressions
It wouldn't.
I think this is a good idea
I鈥檓 not sure why, but when I read 1:n...
I feel this should be splatting n
, so my vote is higher precedence for splatting.
(I also like the anology between function signatures and tuples so the extra comma in one case and not the other seems odd to me)
Edit: sorry, fumbled the buttons.
It would not bother me if 1:n...
parsed as 1:(n...)
either, so I'm ok with either solution.
Most helpful comment
I'm in favor of requiring the comma, unless that would also make the comma required in call expressions.