SE-0257: Eliding commas from multiline expression lists

[allevato (Tony Allevato)]

@anandabits

Personally, I don’t think this would be an appropriate option for a formatter to offer. If it needs to wrap a non-wrapped line it should leave the commas in place. If the user wants a multi-line list without commas the user should explicitly make the choice to omit commas.

There are formatters that exist today for various languages (I'll use prettier and Typescript as an example) that add or remove the trailing comma in a list depending on whether the list is laid out horizontally or vertically. The hypothetical preference that I mentioned seems like it would be a reasonable extension of that.

I'm having difficulty squaring your position here with the one that you expressed in the thread about the style guide/formatter (please correct me if I'm misinterpreting your intent):

@anandabits

If a user is fighting the formatter to breaking code into readable chunks because the formatter is not familiar with the idiom in use there is a significant problem with the tool, not the code.

A formatter should be usable with any idiom a programmer might have good reason to adopt (including new and innovative ones).

Isn't comma elision precisely the kind of idiom that you're suggesting that some programmers would want to adopt for DSL-like use cases? If so, and if hypothetically a highly configurable formatter were to exist, then it's entirely reasonable that a user adopting that idiom would want that formatter to automatically handle it for them and not be told that they have to remove the commas yourself (i.e, "fighting the formatter").

@anandabits

A formatter should focus exclusively on helping me get there as much as it can while always embracing the “first, do no harm”. That principle would be violated if we decide to reject syntax simply because a formatter can’t make an automatic choice about when to use it.

If the language were to support comma elision, then transforming code to use it in cases where possible if the user wishes it doesn't strike me as harmful—rather the opposite. Why is it the formatter's fault, rather than the proposed syntax's fault, if the tool is unable to get the user farther than it can due to inherent inconsistencies in the syntax?

"[...] decide to reject syntax simply because a formatter can't make an automatic choice" isn't the argument I'm making—I mentioned it to illustrate one of many implementation difficulties that arise from the inherent inconsistencies being proposed, and a proposal that suggests such a fundamental change in syntax needs to consider these things. But it's not even formatters that have this problem—clearly human authors are also having difficulty reasoning about the proposed syntax, based on the responses in this thread trying to determine which situations work and which wouldn't.

The fact that SwiftPM—the very kind of DSL that would hope to benefit from this—would need to be completely redesigned to do so just because it uses collections of enum cases is a hard pill to swallow. Using enums in this manner is a fundamental pattern in Swift, and if the syntax can't support it, then that's a very significant limitation.