Hi all,
The review of SE-0439: Allow trailing comma in comma-separated lists concluded on July 14, 2024. The language steering group has decided that the proposal should be accepted with modifications.
Particularly with changes in the language and ecosystem since consideration of SE-0084, members of the steering group agree that there's some benefit to supporting trailing commas more broadly in the language, and that any stylistic concerns can be addressed with code formatting tools (as has been the case for trailing comma support in array literals).
In the case of symmetric delimiters (including (...), [...], and <...>), it's clear that the presence of a trailing comma will not cause parsing ambiguity. This portion of the proposal is accepted.
Reviewers pointed out the difficulty to users of a rule where inheritance clauses and generic where clauses are supported sometimes, if there is an unambiguous terminator that follows but not otherwise. If trailing commas are to be an affordance that improves the user experience, the reviewers argued, then requiring users to think like a parser to determine if they can leave them behind might not hit the mark. The steering group's consensus was that we'd prefer instead to leave out support for trailing commas in inheritance clauses and generic where clauses across the board.
Though there is a proof-of-concept implementation of trailing comma support for condition lists after if or while, we haven't been able to conclude that there's absolutely no corner case where ambiguity can arise in currently valid code. Additionally, there was concern that adoption of this feature could place limitations on future evolution of the language which we cannot foresee. For that reason, even as we recognize that reordering of conditions is a fairly common usage, we would subset out this portion of the proposal. To arrive at a teachable 'resting point' for the language, we will also subset out support for guard...else, which would be incongruous without support for if, and we would also leave out support for case patterns in switch statements.
Lastly, the steering group also discussed some nuances about where trailing commas are supported inside symmetric delimiters. It was noted during review that [Int,] is valid in some contexts but not others. The steering group didn't feel that making this spelling valid in type position (i.e., let x: [Int,]) was the correct approach to addressing this discrepancy. Similarly, many built-in attributes make use of custom parsing for parenthesized contents that aren't treated as comma-separated argument lists; in those circumstances, too, we would not add trailing comma support--for instance, @inline(never,).
Thank you, as always, to all participants in this review process for helping to make Swift a better language.
Xiaodi Wu