The same argument could have been made for semicolons, yet we "know" they don't provide value; or for commas after "case" declarations in an enum, yet of course we wouldn't have those (despite C having them). I look at something like this (grabbed at random)...
let best_pictures = [
1973: "The Godfather",
1989: "Rain Man",
1995:"Forrest Gump"
]
And the commas add nothing except a weird inconsistency at the end with the missing comma . Or an initialization (taken from Alamofire):
let protectionSpace = URLProtectionSpace(
host: host,
port: url.port ?? 0,
protocol: url.scheme,
realm: host,
authenticationMethod: NSURLAuthenticationMethodHTTPBasic
)
The commas add nothing to clarity; they're just line noise, like the semicolons we eliminated before.
Your second statement is factually incorrect: allowing the elision of commas does not break any source code. A correct statement would be "if you remove all commas from all expression lists in existing Swift source code, it will break some of that source code."
The "exceptions" part of the proposal is listing those places, and that list should look very, very familiar to a compiler implementer: it's exactly the same set of places where you would need to write a semicolon to separate two statements. Comma elision and semicolon elision are the same feature, with different contexts.
Now, it is the case that expressions with a leading dot (.foo) are more common in expression lists than at statement scope, so the exceptional cases will come up more often with comma elision. However, given that we've seen very few problems in practice with the semicolon elision rules over the last 5+ years, I'm not concerned that we're actually causing problems here.
Juxtaposition is already restricted by semicolon elision for statements. It's not a viable mechanism for new bricks (which I hope are tasty ones), so this sugar isn't cutting off future evolution.
Regarding the "extra comma" discussion, some times you need to see what the cost of uniformity is (e.g., put commas after everything as a stylistic choice) to challenge your own assumptions. I thought we needed them, and had convinced myself that somehow semicolons were unnecessary yet commas were, and now that I've looked at it a lot closer... I was wrong. We just don't need those commas. They're noise and they get in the way.
I would have thought so, too! My main concern would be around the
foo
.bar
cases, for which we've never had good diagnostics in the semicolon-elision case because it hasn't been important enough. Now we'll have to do it, and all of Swift will benefit because we're applying the same rule more generally.
The other stuff in the IDE works shockingly well. We took the implementation of this and dropped it into SourceKit to see what would break when editing Swift sources where extraneous commas have been dropped, and... it worked. Because semicolon elision has always been a thing, the tools are prepared for it. We don't feel we need any SourceKit/code completion/etc. changes to make this work.
Semicolon elision paved the way for this change, already. We're in a good place to make it, now that we've realized we can.
Doug