Should the Elixir formatter allow trailing commas?

I copied this from my post on the Erlang Forums, since it’s one of my favorite side-effects of permitting trailing commas:

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:

a = [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.

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.)

For some reason I always thought that the trailing comma was always removed as it was causing a compilation error .

I think in macros, that is true, but not for lists, maps, or other collections. So that would be one thing consider if that is the case.

EDIT: The code examples in my first post all execute successfully in IEx.

Indeed, a macro with a trailing comma will raise a compilation error. For example, this code:

defmodule HelloPhoenix.Repo do
  use Ecto.Repo,
    otp_app: :hello_phoenix,
    adapter: Ecto.Adapters.Postgres,

  # ...
end

produces this error:

Compiling 1 file (.ex)

== Compilation error in file lib/hello_phoenix/repo.ex ==
** (SyntaxError) invalid syntax found on lib/hello_phoenix/repo.ex:4:36:
    error: unexpected expression after keyword list. Keyword lists must always come as the last argument. Therefore, this is not allowed:

        function_call(1, some: :option, 2)

    Instead, wrap the keyword in brackets:

        function_call(1, [some: :option], 2)

    Syntax error after: ','
    │
  4 │     adapter: Ecto.Adapters.Postgres,
    │                                    ^
    │
    └─ lib/hello_phoenix/repo.ex:4:36

Rust’s formatter even forcibly adds a trailing comma at places (IIRC) and I love that. Simpler diffs indeed (not in long use blocks that get auto-wrapped by the same formatter however; those are unsalvageable).

So yeah I’m all for that, though I’m extremely skeptical that Elixir will have core language changes at this point. Even if it’s an optional thing that does look simple to us but likely carries a huge price to implement well.

This is because you do not have the square brackets. The parser does not know if some call is a macro.

+1 for trailing commas. They are already supported by the language, so no core change here. Just the behaviour of the formatter to change. Except for function calls but that’s far less useful IMO.

Having the formatter not removing them would already be a great change.

No because I need clarification. There are some good points about inline vs not in the linked thread. I don’t particularly like [1, 2, 3,] and especially not foo("bar",). Also, I’m pretty indifferent to them in general. I appreciate them very much for diffs but I enjoy not having them when reading. I’d almost prefer this be solved in git, kinda like how you can ignore whitespace in blames (and all the various other blame options).

There’s a difference between supporting trailing commas, and enforcing them.

Yeah, that would be ugly and unnecessary IMO (as a one-liner).

Well solid “no” then since I like that it’s not configurable. I don’t even like that line length is configurable. I’d be fine with all or nothing but that would require enforcing syntax in the scenarios that is problematic for not currently supporting them. Though I wouldn’t cry about it if it became an option.

I also realize I didn’t fully read your second post before responding

I don’t think it would need to be configurable (unless I’m missing something)… it could just permit trailing commas at the end. Both [1, 2, 3] and [1, 2, 3,] would be untouched by the formatter. Presumably, this same could work for single-line and multi-line statements as well. It would be up to the user whether or not to use them.

I also prefer to stick to formatter defaults so I’m with you there.

Good point. When I add the square brackets, the trailing comma works (as long as I disable my editor’s format-on-save feature).

Right, I hadn’t thought about trailing commas there either, but I wouldn’t be in a rush to support that.

This is funny timing. I had this discussion with a couple of colleagues on Friday.
Personally I have no strong preference, but it seems that people that have been using Typescript or Rust are quite fond of those trailing commas.

I would prefer that the formatter neither adds or removes trailing commas, as to leave it up to the author.
But I also know that this may lead to quite a few “we need to agree on how to do this”-discussions, as there are different preferences.
Currently, the formatter makes a choice, which we can disagree with, but it is consistent. If it allows both, codebases will be more inconsistently formatted.

I guess the interesting thing is how many people to prefer the default to be changed from removing trailing commas to adding them. Make half developer happy, the other half unhappy?