SE-0257: Eliding commas from multiline expression lists

Not at all, your reply is appreciated. What I meant here is that it is not a reason to reject the proposal out of hand without examining the facts. I did not mean that it isn’t possible for a reasonable person to think that in this situation the details lead them to a conclusion that it should not be accepted. And I certainly didn’t mean to imply that commenters on this thread are not considering the details. All I meant is that it is also possible to come to a different conclusion and it is not so crazy that some of us have.

Since this was pitched, I've been eager to offer motivating examples from folks like me who have experience with this formatting in other configuration languages. The strong opposition from @Chris_Lattner3 and others gave me pause to consider the effects and to request more discussion. I wish the pitch thread had been given more time to explore the ramifications. I feel the thread was shortchanged by some unfortunate passive-aggressive tension in some comments as well as dismissive attitudes that I hope can be forgiven as stress and misunderstandings. Sugar proposals like this can live or die on their own merits.

I'm pleased that the consequences of this change got to be hashed out here. I think the impact on transformation tools is a particularly strong point. I'm persuaded that there are enough nagging issues to make the benefits not worthwhile.


There do exist legitimate arguments against this proposal even if everything "just worked."

One, as touched on by @Ben_Cohen, is the contention that "we've gone beyond that point in the evolution of the language." It might be stated something like this:

  • The aesthetics of a programming language are an important part of its identity and its daily user experience (as reader and writer)
  • Now that Swift has been around for many years, users (and even non-users) have come to identify a certain aesthetic with Swift
  • Removing commas on a wide scale appreciably alters the language in a way that makes it no longer recognizably Swift--in others words, an appreciable number of users (and even non-users) may answer no to the review question: "Does this proposal fit well with the feel [...] of Swift?"

Now, to be clear, I agree with @Ben_Cohen that I don't think we are past the point of such a change. That is, I would like it if everything just worked without commas. But let's not ignore arguments to the contrary.

On this point, I do have to agree with others such as @Paul_Cantrell that inconsistency is a serious problem. I would go so far as to say that, in my view, it necessarily requires rejection of the proposal.

The reason isn't even with regard to the aesthetics of one or two items in a list having a comma and others not having a comma (which as mentioned can be solved with an all-or-none rule for each list). No: the reason that I think it necessarily requires rejection is that even some reviewers here specifically primed to think about this proposal mistakenly thought that they could elide commas from SwiftPM manifests and fell straight into one of the footguns.

I don't know that anyone thinks of the rules surrounding parentheses as "elision."

Moreover, rules surrounding parentheses with commonly used operators are taught in grade school to all children. And as we are all too aware, rules surrounding parentheses with operators not taught in grade school do cause problems, and Swift's rules do in fact require some additional parentheses not found in C/C++ by making some of these operators non-associative in an attempt to address this exact issue.

The proposed comma elision rules here are not taught in grade school to all children: therefore, if we were to make a comparison to the use of parentheses with operators, then the conclusion is that Swift should indeed make a best-effort attempt at not allowing elision.


There is a fundamental advantage with the leading dot syntax that you cannot fully match in a general expression context, no matter how smart code-completion is. The leading dot constrains the available options to only a handful of them, allowing not just helping complete what you type in a more focused manner but even to just browse and explore the available options. For a general expression context you could give higher priority to certain completion results but you are still dealing with a full unconstrained set of global symbols.

I'd like to make the observation that these quotes are a clear indication that comma-elision as proposed is significantly different than semicolon-elision, and has ramifications beyond being just syntactic sugar (no-one needs to spend time thinking about how to design APIs that can take advantage of semicolon-elision). This was not obvious to me before seeing the feedback here.

  • What is your evaluation of the proposal?

I'd personally prefer to leave it as it is or choose an alternative which is to allow trailing comma. I find myself more annoyed with this limitation (not allowing trailing commas in parameter lists, but allowing it in arrays/dictionaries) rather than having to use a comma in the first place, which is so common that not using it feels not just alien but even a mistake, and can be actually a mistake or ambiguity when mixed with other language syntax and use of some operators and syntactic sugars like trailing closures or variadic argument lists.
The argument of trying to make EDSLs nicer in Swift IMO will lead to trying to make it fit with something else (what is already happening with an introduction of some other features) and as a result, we'll have a Frankenstein language.

  • Is the problem being addressed significant enough to warrant a change to Swift?

no, I don't see comma as a noise.
The choice of allowing to drop the comma rather than allowing trailing comma feels more like a personal code style preference rather than a serious argument for the change in basics of the language (same way as a preference of trailing comma is a personal preference, but that's not a suggestion that is being discussed)
Another question to ask - how would it fit if proposal about official Swift style guide will go through, what style will be preferred? This change would allow for more variations in the way people write code which does not help sharing it.
I also think that such experiments with basic grammar of the language, even if it is not breaking, should happen prior to 1.0 version, not at 5.0.
I don't know implementation details but I'd be surprised if this change would simplify implementation of the compiler, pretty sure it will become more complex.

  • Does this proposal fit well with the feel and direction of Swift?

unless the direction is to leave it with a bare minimum of punctuation, but then it will become some different language

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

not related to usage of a comma but in Ruby one does not have to always use parenthesis in a function call, which IMO creates ambiguity when reading the code and is asymmetric to the function declaration syntax where parenthesis are still required (AFAIK), unlike in Haskell. But I definitely would not use Haskell as an example of a language that is easy to read and understand, which is one of the selling points of Swift for people who starts to learn it. Adding another way of doing a simple thing does not improve this experience. I think Swift already has a balanced use of punctuation, which I also think is the most common one.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

a quick reading of proposal and this thread


I've been following this discussion for a while now and was rather ambivalent about this before, but this point puts me solidly in the negative. If this change affects API design, where some designs are more amenable to elision than others, that's not good for the language. I also don't think the comparison to semicolon elision is particularly apt, since semicolons were never about human readability, they were just an aid to the compiler. Commas are not.

So I can safely say I'm -1 on this proposal after reading the discussion threads and the proposal itself.


I'm pretty strongly -1 for the reasons others have mentioned. Possible confusion between things like - x and -x, and future limitations on the growth of the language. Writing a comma just isn't enough of a burden to justify it.

That said, I would be +1 on allowing a trailing comma...

On first reading the proposal I was quite enthusiastic about it, but having now read the entire thread here I’ve changed my view to a strong -1. My main reason being the ambiguity it introduces as @hartbit explained in his post:

I could only be in favour of this change if it was something you never had to think about, either when reading or writing code. The comparison with semicolon elision has often been made, but in that case this condition is true: you literally never have to think about it.

Ambiguity makes code harder to read, and the language harder to learn. This proposal introduces JavaScript level quirks into the syntax of Swift that cannot be a good thing.

1 Like

Strong -1, makes code harder to read

1 Like

-1 for this proposal.

The benefits seem so small. I do not feel they at all make up for the many disadvantages I feel this would result in.

Commas, for me, are hints for parsing the language when reading it. Basically the whole premise of the proposal, that commas are visual clutter, is such a subjective statement which I personally do not agree with. The samples I have seen for comma elision seem harder for me to parse. Granted, it probably is just all about getting used to it. But I really wonder: Why? It makes things less consistent and more difficult for newcomers.

I really appreciate all the work done in the community regarding all this, and deeply respect all the discussion happening in this thread, by both proponents and opponents of this proposal. We all just want Swift to be more awesome. So do not see my -1 as in any way a critique of someone or something.

  • What is your evaluation of the proposal?


  • Is the problem being addressed significant enough to warrant a change to Swift?

No. It's syntactic sugar that sacrifices clarity everywhere, for brevity in a few specific circumstances. I would much rather see allowing trailing commas in an expression list as a solution to half the problem this solves. (Or regardless for the sake of consistency).

Commas are IMO the simplest and clearest form of syntax we have, and adding an additional whitespace-as-delimiter case is something that should be considered very carefully, not just thrown in because some people think commas look ugly.

The only compelling case really seems to be EDSLs, but if that is a capability important to Swift, it should be considered more broadly and directly.

If/when this capability is added, I think it should be constrained and explicitly opt-in. Not ever as a general language feature.

  • Does this proposal fit well with the feel and direction of Swift?

No. It feels like a distraction from adding much needed features and would very likely be problematic to to the already poor (but improving) text editor and IDE support/bugs by adding a complex and unintuitive feature.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Anytime I seen lists without commas it adds a cognitive load to understanding the code I'm reading.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?


1 Like
  • What is your evaluation of the proposal?

-1. I’m not in favour. I think the potential for this feature to introduce unexpected errors by novice (and experienced) Swift users to be quite high.

  • Is the problem being addressed significant enough to warrant a change to Swift?

I do not think so.

  • Does this proposal fit well with the feel and direction of Swift?


  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not (that I am aware of).

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal and many of the comments.

1 Like


It is surprising to me that the proposal makes no effort whatsoever to address a fundamental, credible concern.

I think nothing more than that needs to be said. Frankly, I don't even see how this proposal got this far, given how little thought on Swift's long term goals (clarity, stability, performance, safety) seem to be considered by the author and proponents.

-1 for the proposal.

I do not see any benefits, only confusion will arise. If this is allowed, sometimes people will put a comma and sometimes not. I also think that line wrapping of long lines in code editors makes it hard to see if there is a real separator, or not. In contrast, the comma is very clear and works fine as a separator.

1 Like

+1 for this proposal.

At first, I wasn't convinced. It's a subtle change and one I thought was friviless. However, after looking at @nate_chandler and @anandabits examples and exactly how the changes looked; it starts to make sense. The , becomes noise once you see a world without them.

What really brought it home for me though, was the comparison to the ; - We absolutely should do this, to remain consistent.

-1. As many others have also stated, I have never encountered a case where I needed to add a semicolon, but there will definitely be cases where I have to add a comma.

I do not buy the EDSL argument, quote:

The situation with definition of the table in the EDSL is the same. The commas are providing information to nothing and nobody. They are ceremony for its own sake. Moreover, they are a constant visual reminder that you are looking at a list of arguments being passed to a function rather than a list of declarations in the EDSL.

If something is a Swift function call and is executed like a Swift function call, then I want it to look like a Swift function call. A EDSL should not try to rely on obscure syntax features (and IMHO not use weird custom operators either), but instead provide domain-specific types and functions that allow programmers to work at a higher level of abstraction in that domain.

1 Like

Contributes to developer agility. Readability is not effected as no one really reads commas and skip them in the head anyway.


I mostly followed the pitch thread and read the majority of the review thread.

I agree with all of the concerns raised by @Chris_Lattner3. I have also never thought, "Hey, this code needs less commas" and the fact that it would still be required in certain cases is a big downside. Consistency is extremely valuable in my opinion.

Proposal Returned to Pre-Review Discussion

Thank you to everyone who has participated in the review of this proposal. I am thrilled to see the amount of passion and energy everyone has in making Swift a better language.

This has been a polarizing discussion. It also has not the best conducted discussions we've had in Swift Evolution's history. In hindsight, this review was launched prematurely while important details were still being shaken out in the pitch phase. It was my mistake, as the review manager, to schedule the review before more of that discussion had settled and the concerns in the pitch phase sufficiently addressed. This is a serious change to the language, and it should not feel rushed or insufficiently vetted. As such, I think it is important to allow the proponents of the proposal to have the opportunity to go back and incorporate the feedback from this review and re-engage the discussion, starting at the pitch phase, before we consider re-engaging this topic for formal review. This is not just my desire as the review manager, but the proposal authors have shared the same opinion and desire.

I would like to take this opportunity to reiterate the importance of the Code of Conduct standards for Swift, and the general principles they are meant to impart on how we run the community. I think it is crucial that reviews should be held to high standards, but we should always refrain from criticizing the review authors or otherwise engaging in what can be perceived as personal slights. Everyone engaged on Swift Evolution is interested in making Swift better, and it takes a lot of guts to write a proposal in the first place and debate it with the community. It is fine to remark that a proposal feels premature to review and that important things need to be considered — but let's avoid taking it beyond that and making comments about people themselves. Everyone has good intentions here, and everyone should be given the benefit of the doubt even when making mistakes. I hope everyone who participated on this review thread and on the pitch can step back and ask how they would have preferred the discussion on the thread could have gone a bit better, either in their own participation or the participation of others. In every review discussion, let's make sure we learn as a community from that experience so we can continue to find the best way to engage in topics like these that are contentious but are all in the spirit of making Swift better.

I want to extend my sincere thanks to the proposal authors, @nate_chandler and @anandabits, and to everyone who participated in this review.

Terms of Service

Privacy Policy

Cookie Policy