SE-0257: Eliding commas from multiline expression lists

Evolution Proposal Reviews
140

But that's precisely the point I'm making and why I come down on the side of "no comma elision"—it doesn't and can't fully and consistently solve the problem that it wishes to.

For what it's worth, I could be convinced of "yes, comma elision" if it could be applied successfully to all scenarios where a comma-delimited list was laid out vertically and have the commas removed. While I still don't think the visual weight of commas is as severe as the proposal claims, I would be more supportive (and might even adopt it!) if it could be done universally. But that's not possible, because something as simple as this could have two different possible interpretations:

let x: [SomeEnum] = [
  .y
  .z
]

Based on that, I can appreciate that your opinion differs on this and that the language should support it where it can, but I simply don't think the wins are significant enough to introduce more inconsistency in the language to make it possible only in some cases.

2 Likes
141

The principle I adopt is that code is read far more often than it is written. Formatting choices should therefore be made for the benefit of the reader . A formatter is a tool that can help ensure consistency, especially in the areas of microformatting decisions. But it is no substitute for care by the author

This feels like words from someone who has not spent much time using a (really exceptionally good) automatic code formatter (edit: apologies I didn't mean that to be disparaging — i meant that comment based my experience with code formatters of lower quality vs say - javascript's prettier). JavaScript’s prettier in my experience never transforms hand-crafted artisanally formatted code into a less readable version. I would also argue that time spent reading code is often most fruitfully accompanied by editing that code — the speed with which a language learner can get feedback about unfamiliar language constructs by interacting with code in the presence of a good formatting tool shouldn’t be ignored — you can often come across some syntax you aren’t 100% familiar with, add some lines or characters, rerun the formatter, observe how the formatter thinks the code should look to learn something about the intended semantics of a construct without having to read documentation.

Embracing opinionated automatic formatting as a language feature would be to me an acknowledgment that editor-level tooling can and should help reduce the grammarian burdens of the code authoring experience. In this case, I think baking heuristics into the formatter to be able to understand comma-ellided parameter lists so that it can rewrite them with commas would deliver all the benefits of this proposal while also preserving precise unambiguous readability ...

2 Likes
142

I'll repeat the line of reasoning based on parentheses elision. We don't demand that it be possible to omit parentheses in 100% of cases in order to achieve the desired behavior. Why should we demand this of commas? It might be reasonable to argue that parentheses elision is much more important to the ergonomics of the language than comma elision, but that is a subjective determination. My point is that these are not categorically different and (obviously) reasonable people are making different determinations.

143

Elision in one place doesn’t mean we should allow elision everywhere, because not all kinds of elision are the same. This may be a subjective statement, but IMO the rules around parenthesis elision (simple vs complete signatures) are far more consistent and understandable than the proposed ones around comma elision, which are based on whether the thing on the next line could potentially be parsed as part of the same expression and which precludes very obvious use cases like arrays of enum cases or other implicit static member references.

1 Like
144

• What is your evaluation of the proposal?

-1

I understand the analogy between optional semicolons and optional commas, but it seems to me that semicolons are optional because statements are normally written on separate lines. It's convenient to use semicolons occasionally, when grouping short statements on the same line (e.g. in a one-line function definition), but that's an occasional usage.

With commas, the situation is reversed. Multiple expressions are normally written on the same line, and commas are needed as separators. Having a rule that says they can be omitted if the expressions are written on separate lines creates code that I find harder to read. I have to mentally add commas where they're not written.

I don’t think it’s helped by the fact that I also have to learn a set of exceptions where I shouldn’t (mentally) add commas.

I'd much rather have trailing commas!

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

Quick reading of the proposal. I’ve also been following the discussion.

2 Likes
145

I've moved from reluctantly +1 to reluctantly -1, because of the implications of the following:

  • I have not seen or managed to come up with a single example where a semicolon is necessary at the end of a line. (good)

  • I have seen and can come up with lots of examples where a comma will be necessary at the end of a line. (not so good)

Or put differently:

  • A semicolon at the end of a line is never needed.

  • A comma at the end of a line will sometimes be needed.

The above makes comma elision (as proposed) much more complex and confusing than semicolon elision (as can be seen from much of the discussion here).

However, note that comma elision would be exactly as straight forward as semicolon elision if we restricted it so that it was "only" allowed for:

  • dictionary literals
  • fully-labeled argument lists
  • parameter lists (unlabeled params still have eg _ arg: so they're ok)
  • fully-labeled tuples

That is, comma elision would only be allowed in contexts where commas are truly redundant (the labels/keys and colon makes them so), and (afaics) this way all commas could be elided without ambiguities, not only the ones at the end of a line.

Since the label/key and colon is effectively, well not strictly a separator, but rather a "bullet point" or introduction to each item, perhaps array literals and other un- or partially labeled constructs could be allowed provided they too used an item-introducing colon even for the unlabeled items:

let a: [SomeEnum] = [
  _: .foo
         .bar
  _: .bar
  _: .foo.bar.foo
         .bar.foo.bar
  _: foo _: foo.bar _: foo
]

print(
    _: "Hello"
    _: "world"
    separator: ", " // ;-)
    terminator: "!\n"
)

func dividingClosed(
    _ other: Polycurve
    straightIntersections: Bool = false
    threshold: Float = 1/64
) -> (
    inside: [Polycurve]
    outside: [Polycurve]
    intersections: [Float]
)
{
    ...
}

let package = Package(
    name: "Paper"
    products: [
        _: .executable(name: "tool" targets: ["tool"])
        _: .library(name: "Paper" targets: ["Paper"])
    ...

(No, the _: is not pretty, I agree, it's just a first attempt to come up with something that makes my envisioned more consistent comma elision work also for unlabeled constructs.)

146

Thanks for calling this out here. The proposed change does only cover the elision of commas from expression lists, not all comma separated lists.

Speaking personally, that sounds like a reasonable modification for the core team to consider.

1 Like
147

I agree with this as well. It would be my preference to see all comma-separated lists treated consistently throughout the language.

148

Problem is, that all comma separated lists throughout the language are not equally possible to treat consistently.

As mentioned above, the only ones that can be unambiguously treated are those whose items are reduntantly comma separated, ie the ones in which each item is preceded by a (label/key and) colon.

149

Let's not build strawmen. I am not making the claim that elision in one place implies we should allow it everywhere. I am drawing an analogy between one form of separator punctuation and another and using human experience with one form to consider how humans will react in the presence of the other form.

I'm not sure what you mean by simple vs complete signatures. I was referring to complex expressions that rely on operator precedence (potentially of user-defined operators and precedences). It is possible to write expressions that are quite difficult for humans to parse accurately due to parentheses elision and this is not a problem - humans are quite capable of exercising good judgement about when parentheses are necessary for readable code. We are quite capable of learning to apply the same kind of judgment with regard to comma elision.

150

You misunderstand what I mean. I mean that I think the language should apply consistent rules related to comma elision everywhere comma-separated lists occur. I don't mean that elision should be required everywhere or applied indiscriminately. I think I have made that point abundantly clear several times now.

151

I know perfectly well what you meant. I think you might have misunderstood what I meant though ; ), see my previous post that I referred to.

152

I think the objection that many people have, and which I share, is that issues with and exceptions to existing elision rules (parentheses, semicolons, whatever) are generally encountered in fairly pathological cases. OTOH, it seems like heavy users of comma elision will likely run into one of these exceptions in practice, since the exceptions arise from pretty commonly used constructs like enum cases and static members.

I'll also echo @Chris_Lattner3's desire for some kind of data about how much existing code could make use of this feature without running into any of the exceptions that have been discussed.

6 Likes
153

That is an interesting approach, but I would still prefer to see the same rules applied to all comma separate lists in the language. As with parentheses, I think programmers are quite capable of learning when commas are necessary for clarity and correctness. The rule you advocate would ban some great use cases for this proposal and introduce undesirable (IMO) special cases into the language rules.

154

Isn’t this exchange actually a perfect example how this change introduces confusion? You suddenly can’t tell anymore at a glance whether the expression runs on or not.

There was another snippet posted which I started at and had a hard time parsing. That’s when I realised that commas serve as delimiters for my visual parsing in ways line breaks often don’t.

Yes, the counter argument is that I can still use commas but I’m not only reading my own code.

And I wonder if I’d start questioning expressions broken up across lines because it could perhaps also be a list with comma elision - even in my own code. God knows I often can’t remember if I’ve written it or a colleague...

2 Likes
155

Well, with something like the attempt I made (in the last part of the post) to include all comma separated lists, the rules would be simpler than with the current proposal, since there'd be no ambiguities, or even need for commas, they'd be a purely aesthetic choice. The _: (of my said attempt) is arguably worse than a few unavoidable comma separated lists here and there though, but it's much more consistent.

I think comma separated lists might be even worse if they are here and there instead of simply everywhere. We'd probably find ourselves thinking way too much about why/if some particular list really must have commas, or how we might possibly get rid of them, or get a bit disappointed that we really do have to add commas because we have to edit an item in a way which makes them necessary.

156

Nobody complains about needing to use parentheses to write (a + b) * c or thinks we should require parentheses everywhere for consistency. IMO commas under this proposal fall into a very similar category. It’s ok if you and others have a different opinion about this. The core team has a tough decision to make!

This just introduces a new kind of inconsistency. Now _: is sometimes necessary and sometimes not - i.e. it is required for multiline lists without commas when there is no label otherwise required. I think the rules are simpler if we just allow comma elision and rely on users to develop good judgement about when to use commas to pre-empt any potential confusion just as we do with parentheses in expressions where operator precedence requires it (or where we don’t want to rely on readers to understand precedence).

2 Likes
157

  • What is your evaluation of the proposal?
    -1

  • Is the problem being addressed significant enough to warrant a change to Swift?
    No. This proposal introduces visual ambiguity without improving the use of the language in any meaningful way. A comma is visually lightweight, not some kind of burden on readability, and in my opinion helps improve readability.

    A lot of people who are in favour of this proposal seem to want it because they want the flexibility of moving around parameters in a function, which is hampered by disallowing trailing commas.

    If that is such a big concern, a better alternative would be to allow trailing commas, like so:

var result = foo(
    bar,
    baz,
)

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

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

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
    Read through the proposal and looked through a handful of comments.

158

… or where we have no choice but to use commas, even though we didn't want to or think we had to, as in:

let package = Package(
    name: "Paper"
    products: [
        .executable(name: "tool", targets: ["tool"]), // :´(
        .library(name: "Paper", targets: ["Paper"]), // :´(

This is a good example of how comma elision (as currently proposed) isn't nearly as nice as I first thought it would be. I saw your reaction to this before and I agree to leave it to the core team.

(EDIT: Removed a misquote)

3 Likes
159

I think this is the part where I disagree. They don't feel like a similar category to me. Parens group logical chunks of thought or priority. Commas separate between members of a group of some sort.

So in spite of the fact that both can be omitted, and also semicolons, commas are in a different usage group for me.

5 Likes