[Rejected] SE-0084: Allow trailing commas in parameter lists and tuples

Proposal link: swift-evolution/0084-trailing-commas.md at master · apple/swift-evolution · GitHub

Hello Swift Community,

The review of SE-0084: "Allow trailing commas in parameter lists and tuples" ran from May 10…16, 2016. The proposal is *rejected* for Swift 3.

The feedback from the community was quite divided on this topic: many people contributed to the discussion thread with some people agreeing and some disagreeing.

Swift currently accepts a trailing comma in array and dictionary collection literals, for three reasons: evolution of a project often adds and removes elements to the collection over time, these changes do not alter the type of the collection (so those changes are typically spot changes), and the closing sigil of the collection (a right square bracket) is often placed on the line *following* the elements of the collection. Because of these properties, accepting a trailing comma in a collection literal can help reduce spurious diffs when elements are added or removed.

That said, these properties do not translate to other comma separated lists in Swift, such as variable bindings in a var/let declaration, parameter lists or tuples. For parameter lists and tuples (the specific topic of the proposal), the trailing terminator of the list is typically placed on the same line as the other elements. Further, changes to add or remove an element to a parameter list or tuple element list change the type of the tuple or the signature of the call, meaning that there is almost always changes in other parts of the code to allow the change to build. Finally, the core team does not want to encourage or endorse a coding style that puts the terminating right parenthesis on a line following the arguments to that call.

Thank you to Grant Paul and Erica Sadun for driving this discussion and proposal forward.

-Chris Lattner
Review Manager

To be honest, I was hoping the core team might agree that they be allowed just at call-sites, where changes would not propagate to other parts of the code but allow the easy inclusion and exclusion of defaulted arguments.

Sad to see this one go down but gratified that it got a fair consideration. Thank you again, -- E

···

On May 25, 2016, at 9:37 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Swift currently accepts a trailing comma in array and dictionary collection literals, for three reasons: evolution of a project often adds and removes elements to the collection over time, these changes do not alter the type of the collection (so those changes are typically spot changes), and the closing sigil of the collection (a right square bracket) is often placed on the line *following* the elements of the collection. Because of these properties, accepting a trailing comma in a collection literal can help reduce spurious diffs when elements are added or removed.

That said, these properties do not translate to other comma separated lists in Swift, such as variable bindings in a var/let declaration, parameter lists or tuples. For parameter lists and tuples (the specific topic of the proposal), the trailing terminator of the list is typically placed on the same line as the other elements. Further, changes to add or remove an element to a parameter list or tuple element list change the type of the tuple or the signature of the call, meaning that there is almost always changes in other parts of the code to allow the change to build. Finally, the core team does not want to encourage or endorse a coding style that puts the terminating right parenthesis on a line following the arguments to that call.

Hi :wave:

after the introduction of XCode 15's shortcut Refactor -> Format to Multiple Lines (control+M) we see that the automatic formatting given by Apple is with
) {
on the line after the last parameter.

Should we reconsider this feature for function parameters?
The consideration

the core team does not want to encourage or endorse a coding style that puts the terminating right parenthesis on a line following the arguments to that call

doesn't seem to apply anymore. What do you think?

Examples:

7 Likes

Firstly, a huge thank you for bringing control+M to my attention. That's literally going to cumulatively save me days or even weeks of my life that I would have spent continuing to manually format.

Secondly, just so you know, there are some norms of the forum that would dictate that you make a new post in which you link to this very old post for context, instead of commenting directly on the very old post. See one relevant discussion on the topic here.

Thirdly, since I'm already posting on this bumped thread, I'll mention that I think I'm very much in favor of the idea. Especially now that we have variadic generics that allow comma-separated function arguments to play a role that used to require arrays, I think the occasions where one would wish one could end with a comma will be even more frequent. Yesterday while I was playing around with macros and editing the names parameter in @attached(member, names:) I probably bumped into the lack of this feature 10 times in the span of 20 minutes as I commented in/out arguments to the names: parameter.

@davide , you mind making a new post about this (in which you link to this one) so that we can continue the discussion without producing undesired notifications?

5 Likes

Created here

2 Likes