Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

require (x...,) instead of (x...) to make a tuple? #24452

Closed
JeffBezanson opened this issue Nov 2, 2017 · 5 comments
Closed

require (x...,) instead of (x...) to make a tuple? #24452

JeffBezanson opened this issue Nov 2, 2017 · 5 comments
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax

Comments

@JeffBezanson
Copy link
Sponsor Member

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.

@JeffBezanson JeffBezanson added needs decision A decision on this change is needed parser Language parsing and surface syntax labels Nov 2, 2017
@Keno
Copy link
Member

Keno commented Nov 2, 2017

I'm in favor of requiring the comma, unless that would also make the comma required in call expressions.

@JeffBezanson
Copy link
Sponsor Member Author

unless that would also make the comma required in call expressions

It wouldn't.

@ZacLN
Copy link
Contributor

ZacLN commented Nov 3, 2017

I think this is a good idea

@andyferris
Copy link
Member

andyferris commented Nov 5, 2017

I’m 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.

@andyferris andyferris reopened this Nov 5, 2017
@StefanKarpinski
Copy link
Sponsor Member

It would not bother me if 1:n... parsed as 1:(n...) either, so I'm ok with either solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

5 participants