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 = (
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.
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.
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:
though that's pretty horrible and wouldn't really fly through any style guide in a Swift project
The ability to #if around an extra parameter without a world of pain is also a great example for allowing this!
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.
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.
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.
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