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

Allow trailing comma in tuples, arguments and if/guard/while conditions #2344

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

mateusrodriguesxyz
Copy link

@jessbennett
Copy link

Where are your GitHub checks?

@rjmccall rjmccall added the LSG Contains topics under the domain of the Language Steering Group label Apr 1, 2024
@mateusrodriguesxyz mateusrodriguesxyz marked this pull request as ready for review April 23, 2024 13:38
```

> [!NOTE]
> A similar proposal was [rejected](https://forums.swift.org/t/rejected-se-0084-allow-trailing-commas-in-parameter-lists-and-tuples/2777) back in 2016 for Swift 3. It's been 8 years since that, the swift language has evolved a lot, some changes highlighted above as motivation, and the code style that "puts the terminating right parenthesis on a line following the arguments to that call" has been widely adopted by community, swift standard library codebase, swift-format, docc documentation and Xcode. Therefore, not encourage or endorse this code style doesn't hold true anymore nor is a reason for rejection.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SE-0084 explicitly proposed not allowing trailing comma in single-element tuples.

So that this proposal text meets the standard of describing the solution with sufficient detail that someone else can implement it just by reading the text, I think this proposal should spell out explicitly the grammar changes proposed, which includes calling out whether trailing comma is allowed in single-element tuples, as well as zero-element tuples and parameter lists—e.g., is (,) equivalent to () (aka Void)?


### Allow trailing comma anywhere there's a comma-separated list

Although this proposal focuses on the most requested use cases for trailing comma, there's other places with comma-separated list and the restriction could be consistently lifted for all of these.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing from this list are variable bindings, e.g., var a, b, c.

Also worth calling out explicitly (in the proposed solution) is whether this proposal will support var (a, b,) = (1, 2,), or whether only the right-hand side is allowed to have a trailing comma—in other words, whether a tuple pattern counts as a "tuple" under the proposed solution.

default:
...
}
```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the justifications offered (which you should feel free to include in the text here) for expanding support for trailing commas is growing developer expectation, with many popular languages offering support. As folks have replied on the pitch thread, many languages either choose to stop at arrays/lists or support trailing commas basically everywhere that commas are used as delimiters.

Is there a principle or justification that underlies this proposal expanding support to include tuples and arguments, and control flow conditions other than switch, but not these future directions? If so, can you articulate it here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm pro adding everywhere that is possible but I chose the ones that I personally considered more demanded for scope reason. I did considered add more during the implementation review but @ahoppen rightly pointed that the review had already dragged too long so we went with just the proposed here. And to be honest, this has been more time-consuming than I expected so if possible I would prefer to not expand the proposal. If this is approved and there is a desire to expand, I would be willing to make another proposal expanding to more places.


## Source compatibility

This change is purely additive and has no impact on existing code.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, or the above section, might be a good place to include your findings regarding the implications for parsing condition lists that you've mentioned in the pitch thread. Even if how they're parsed is formally never ambiguous to the compiler, if there are scenarios in which a reader could be confused/misled due to how trailing commas are parsed in condition lists, it'd be good to record for posterity what the intended behavior is.

@mateusrodriguesxyz
Copy link
Author

@xwu I have updated proposed solution and source compatibility sections to address your feedbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LSG Contains topics under the domain of the Language Steering Group
Projects
None yet
4 participants