I think this proposal would be a moderate improvement to Swift. Being able to comment function arguments in and out without fiddling around with commas would be a welcomed improvement for me. But having to fiddle around with commas isn't a difficult problem to overcome, and it's far from the worst thing about writing modern Swift.
I do share the same concerns as many other community members here, though, that this proposal is likely to encourage people to put the terminating right parenthesis of multi-line function calls on the next line rather than putting it next to the last argument. This is bad because:
-
It uses an entire line of code just for a single parenthesis. And the parenthesis isn't even useful for anyone reading the code! You can already see where a function call ends just by looking at the indentation of the code, so this style makes the entire line of code a waste of valuable screen space.
-
Having multiple different options for doing similar things contributes to fragmentation in the community. Fragmentation makes it harder to reuse code across codebases because you have to reformat the code to fit that codebase's style. Additionally, you need to remember the rules for each codebase you work on. By standardizing on minor formatting details, Swift code looks generally consistent and programmers don't have to weigh the pros and cons of each formatting style.
I also don't like the way this proposal encourages the developers of macros to use it. When macros were introduced, one of their main selling points was that macros are transformed into regular, readable Swift code — one of the first things demonstrated about macros in WWDC23's State of the Union was Xcode's "Expand Macro" feature. This proposal encourages macro developers to make their code less readable by adding extra commas where regular Swift code wouldn't. Plus, it doesn't really fix the underlying problem that creating lists in plugins and macros is a poor experience. You'd still have to special-case code in if/guard statements, for example, because they don't support zero-element condition lists. Rather than encouraging people to abuse trailing comma functionality in order to make writing macros easier, I think we should make writing macros easier by adding functionality to swift-syntax to generate normal-looking lists easier, among other things. (Currently, doing something as simple as properly parsing a float literal practically requires a third-party library!)
I'd like to see this proposal get accepted, but only if we can be reasonably sure that this won't further encourage people to adopt the "useless parenthesis" style of code. Personally, I think it's pretty risky. There are plenty of posts in this very thread with people saying that they plan to use trailing commas this way. And, as the proposal points out, plenty of official Swift projects use this style including the standard library, swift-format, DocC, and the default package templates. swift-syntax also uses this style pervasively, as well as the "mandatory self" code style that was rejected (for reasons that are still valid!) with SE-0009. If the Swift project can't follow these formatting rules consistently, then how can we expect individuals and other organizations to?