Permit coma before the enclosing ]

Erlang/OTP Proposals Proposals: Ideas
,
1

I propose to make this kind of code legal:

[
    element_a,
   element_b,
]

not the extra “,” before the enclosing of the ] parenthesis.
The same apply to map:

#{
    a => 1,
   b => 2,
}

The main reason for me is to make easier messing up with the tests in the ct common test enabling/disabling it without having to specify the list of the test from the command line.

The other reason is that this allowed in language like Elixir so could be a little improvement to commonize this behavior.

8 Likes
2

While this is annoying for sure, I’m not sure it is enough to warrant an addition to the language. What other use cases are there?

EEP-0021 from 2008 suggests the same things and the discussion around it is available on the old erlang-questions mailing list. I wasn’t around at that time so don’t know why it was not accepted, but the discussion tends to come up from time to time :slight_smile:

8 Likes
3

Thanks a lot for point me in the right EEP.
I think that there are these use cases:

  • easily moving and grouping the record field or the exported functions without worrying about where is the coma
  • easily moving deps in the rebar config
  • easily commenting/decommenting tests on ct suite
  • having the same behavior of Elixir
7 Likes
4

Another use case is smaller diffs in some scenario’s, like updating deps in an app:

- some_dep
+ some_dep,
+ new_dep

vs

+ new_dep,

The benefit here is more concise diffs and no “unrelated” or “irrelevant” line-changes.

3 Likes
5

Ah the old separator-vs-terminator discussion.

Some or us adapt a comma-first convention which gives most of the same benefits as allowing a trailing separator before the closing symbol.

2 Likes
6

if you mean:

[
a
, b
, c
]

you still have a special case: the first element of the list (the a)

2 Likes
7

If your list is

[
 b
 , c
]

Adding a would give you a diff like

- b
+ a
+ , b

Or, if you’re a psychopath :wink:

+ , a

However those of us who use erlfmt are not getting into the separator-vs-terminator discussion :smile:

2 Likes
8

From my perspective (also a comma-first fan, but also an erlfmt user), this is the most relevant reason to permit trailing commas in list-y things: To avoid using a hack in the formatter to deal with them producing code that’s not exactly what I wrote.

In other words, I want to use erlfmt without being surprised by it changing my code (beyond formatting it, of course) when I run it. If trailing commas were allowed by the language, there would be no reason for erlfmt to remove them from my code :slight_smile:

1 Like
9

As noted, this was raised back in 2008. I find the argument from Elixir has more weight for Erlang than the argument from Python. Or it would if I found Elixir syntax less repugnant. Rebar didn’t exist back then. And there have been much bigger additions to Erlang syntax since. Perhaps it is time to revisit this topic.

By the way, I really don’t want any comas when dealing with Erlang. Commas are Ok, but no comas.

2 Likes
10
  • Trailing commas should be supported
  • I don’t care, I just wouldn’t use them (or format them away)
  • I don’t like them and don’t want to see them supported at all
0 voters
3 Likes
11

Last time I checked, the official Elixir formatter removed trailing commas,
and it was not configurable.

Maybe that’s not the case anymore though.

1 Like
12

If trailing commas were supported, I feel the best default would be to add them as lines could then be moved/deleted at any position with the benefits mentioned above.

I think it would be hard/impossible to make a formatter automatically add commas in the middle if e.g. the last line without comma was moved earlier in a list.

Whereas it is always safe to add a trailing comma if one is missing.

1 Like
13

Some like commas first so we should support extra leading commas too. Also if a mix of trailing comma and leading comma is encountered that should be OK too. So really just any mixed bag of commas and whitespace would be OK. That way lies madness.

4 Likes
14

commas first are just an hack because u don’t have the trailing one :wink:

3 Likes
15

Just my $0.02…

I’m not a fan of allowing trailing commas really, but I wouldn’t mind too much either. I just wouldn’t use them, that is I like my code tidy :wink:

However, the same case that would justify trailing commas could be made for function/case/if clauses and the semicolon. And allowing trailing semicolons I would definitely object to.

6 Likes
16

I didn’t like the trailing commas idea to begin with, and now you have given me nightmares with trailing semicolons in them… Thanks @Maria-12648430 :zany_face:

4 Likes
17

My pleasure, be my guest :grin:

2 Likes
18

If they get added I think it would make most sense to only add them to all ”collections”, i.e. lists, maps, tuples and records.

I too wouldn’t want them for expressions (even though the same argument could be made there as well of course).

2 Likes
19

I was about to say the same. I actually posted a thread about this on EF a while back:

1 Like
20

(I’m primarily an Elixir developer so I don’t know if my understanding of the situation carries over to Erlang.)

I’m not here to extol the virtues of Javascript, but they did get one thing very right by allowing optional trailing commas.

As mentioned by others, this allows for simplified diffs, but one major benefit IMO is that some of the auto-formatters (e.g. Prettier) allow the trailing comma to be used to define how a (short) list of items is formatted.

Given a short list of items:

[1, 2, 3].

If a trailing comma is placed at the end of a list, e.g.:

[1, 2, 3,].

Then the formatter will automatically split it into multiple lines when it is applied (e.g. on save, if auto-format-on-save is enabled):

[
  1,
  2,
  3,
].

(This looks silly for a short list like this, but it demonstrates the point. It is nice to use for more complex data structures.)

Conversely, if the trailing comma is removed, then shorter lines will automatically be merged back to a single line. Longer lines will be split into multiple lines as needed (to maintain the configured max line length), and will have the trailing comma, as one would expect.

This feature is nested as well, so you have the ability to determine which structures can be placed on one line, and which should be split up into multiple lines:

[
  #{hello => world, goodbye => troubles},
  #{
    hello => world,
    goodbye => troubles,
  },
].

It’s a small syntactic difference that can lead to much more readable code, IMO.

@carlotm Elixir removes trailing commas by default (a mistake IMO, as it precludes the ability to apply the aforementioned formatter trick), but there is a custom formatter called Freedom Formatter which apparently implements this feature. (I have not used it myself since I prefer to stick to conventional code styles when possible, even if I prefer the customization.)

1 Like