SE-0257: Eliding commas from multiline expression lists

[Douglas_Gregor]

@Chris_Lattner3

This sort of proposal makes Swift less uniform and pushes it towards the direction of Perl, where early in its life, people spent time trying to "make syntax work" and it turned into a pile of special cases.

The same "special case" already exists for semicolon elision in statements.

@Chris_Lattner3

This proposal is akin to allowing the colon to be emitted between a variable name and a type (golang style) in certain cases. Yes, it could be done in certain cases, but not all, and the irregularity introduced would harm the language for almost zero benefit.

This analogy does not fit at all. The closest analogy is eliding semicolons between statements; it is literally the same feature.

@Chris_Lattner3

No, it reduces clarity, and introduced grammar ambiguities that don't otherwise exist. What is the meaning of this code, and why do we want it to be "unclear"?

var x : Any = [
    foo
    (6 * 9) // Function application or separate value?
]

It's a separate value, just like if you wrote

foo
(6 * 9)

in today's Swift.

@Chris_Lattner3

The "When will you still use commas " section points out several other weird and non-obvious cases that make the language harder to understand.

There is literally nothing new in that section: these are the rules of Swift's grammar today for semicolon elision with statements. There is a practical difference in that you're more likely to bump into these cases in an expression list (comma elision) than in a statement list (semicolon elision).

@Chris_Lattner3

If this proposal were to be taken seriously, it should also allow omission of the semicolon in single-line statements lists "in the cases when it could work".

This does not follow at all from the proposal. The proposal applies precisely the same logic used for semicolon elision of statements to comma elision of expression lists; it does not otherwise expand the rules.

@Chris_Lattner3

I've participated into this in the various incarnations that have spanned various pitch threads. The concerns I raised before have not been addressed.

For reference, I posted an extensive reply to your critique within the pitch thread, to which you did not reply.

@Chris_Lattner3

The entire premise of this proposal is that separators do not provide value to humans. This is not obviously true and I would like to see some evidence to defend this position.

(I'll separately post my own thoughts on this part, which are quite subjective)

@Chris_Lattner3

As you point out in your 'exceptions' section, the Swift grammar relies on juxtaposition and sequencing as part of the existing grammar. This is a source breaking change for at least some cases.

As I noted in my reply on the pitch thread, this is incorrect. Specifically, I wrote:

@Douglas_Gregor

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.

@Chris_Lattner3

Taking this significantly restricts future evolution of the language, by taking away juxtaposition from the expression grammar. This is extremely problematic for me given the early development of the Swift language. We should not be pouring sugar in as tasty mortar to fill the grammatical cracks in the Swift building - we need to be able to drop entirely new bricks into the language in the future, and that sugar will get in the way, and make evolution much more difficult.

Also as I noted in the pitch thread, this is incorrect. Specifically, I wrote:

@Douglas_Gregor

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.

(skipping the more-subjection comment, so...)

@Chris_Lattner3

I suspect that this will significantly regress QoI on error diagnostics in common cases in the user/IDE experience.

To which I replied in the pitch thread:

@Douglas_Gregor

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.

Our 8+ years of semicolon elision have prepared the language and tools for this change. So while it is a significant stylistic change to the language, it is not a radical technical change.

Doug