Allow trailing commas in parameter lists

Evolution Pitches
21

One more thing that has happened since, if we are looking for "what's changed" arguments, is the growing desire to expand #if to more cases while preserving the syntactic approach Swift currently has. The emerging rule seems to be that if there is some "repeating" element, you should be able to #if it, and that we should get these all done in one go rather than dribbling them in one proposal at a time is the current approach. So you should be able to #if attributes, collection elements, enum cases, switch cases, else if blocks, and... tuple elements and function arguments.

In this brave new world of #if expressivity, you obviously need to write this:

let t = (
  a,
  b,
#if P
  c,
#endif
)

Now, can this be worked around with some special case rule that says the commas are allowed only in this kind of circumstance? I guess. But why not just generalize, since it's desirable to allow this for the other reasons given.

32 Likes
22

Another place where trailing comma would allow better usability when commenting and moving lines is if let and guard let.

9 Likes
23

This is a great point, and also reminds me that it isn't just commenting out the last entry that causes pain – it's also swapping the last and prior argument.

12 Likes
24

I also bump into this fairly often, but this still seems like something the IDE should solve, it would be trivial to add this as an option.

Since it already supports the multiline function signature style, it makes sense for xcode to support the corresponding commenting and line swapping.

1 Like
25

I'd love to have this some day. There are pathological cases to think about if to apply it in other contexts (e.g. inside a tuple that could degenerate to zero or 1 element tuple or inside a dictionary literal that could degenerate to zero elements literal) but even with gotchas like that it would be super useful.

26

As personal opinion, I always wish languages would allow this -- it's very cool during refactoring to be able to do this and easily add / omit parameters without the annoying "change the other line too".

I've seen haskell developers "solve" this by doing:

one
, other 
, another

though that's pretty horrible and wouldn't really fly through any style guide in a Swift project :wink:

The ability to #if around an extra parameter without a world of pain is also a great example for allowing this!

Overall, please let's revisit! :slight_smile:

13 Likes
27

Another +1, run into this daily too and is irritated at the friction.

3 Likes
28

You don’t even need #if to encounter issues with single-element tuples. Should (foo,) parse the same as (foo), or should it be rejected?

I would expect the compiler to reject a tuple expression that contained child tokens which all expanded to empty space, so I think I’m also on the side of rejecting (foo,) and anything that expanded to it.

1 Like
29

We do allow [foo,] today. (foo,) doesn't look much different.

2 Likes
30

The difference is that [foo] is an array literal, while (foo) is a type.

31

Single-element tuples are already allowed today, with the caveat that they behave exactly as the underlying type. (_: 2+3) / 5 is 1.

2 Likes
32

If this is allowed today I don’t see why (bar,) shouldn’t.

1 Like
33

In the spirit of simplifying the syntax, in the same way that the semi-colon was removed as a line terminator, it could also be "nice" to just omit the comma as a separator for multi-line parameters, including arrays and dictionaries.

4 Likes
34

If a syntax like [foo,] is allowed for Array literals, I don't see any reason why (bar,) would not be.

Of course you rarely see [foo,] for single element Arrays, but the language doesn't prevent this

2 Likes
35

I've seen haskell developers "solve" this by doing:

I wish I could unsee that, but it's etched into my retina now. Ktoso, what did you do?

:joy:

2 Likes
36

Personally, I also would love to see this revisited for the same reasons as @Ben_Cohen outlined here. The place where it happens the most to me is actually the Package.swift where I sometimes want to enable something like swiftSettings but then comment them out again etc.

11 Likes
37

What we really need for this is not language support, but smart diff-tool support.

There are also other cases where the current diff tools fail to provide support. Should we then pitch for language support for them?

1 Like
38

I've just found another possible benefit in kotlin coding convention that aligns with new capabilities provided my macros:

It simplifies code generation, for example, for object initializers. The last element can also have a comma.

5 Likes
39

What we really need for this is not language support, but smart diff-tool support

@ibex10 what @mtsrodrigues' link to the Kotlin documentation shows is that the benefits go beyond diffing, and that other languages have added support for this because it makes life easier for developers

1 Like
40

Totally agree that this would be great to be able to do, though the strongest argument to me isn't diffing commits, but the experience when adding/removing/reordering parameters at call sites.

Every time. Every single time!

8 Likes