Oooo, I did not know it had this inconsistency… I may need to start adding an ending optional ignored argument to all my multi-line (mostly macro) functions so I can keep , at the end. 
The language has a ton of ‘surprising’ cases like this already, this would actually remove one of the surprises if trailing commas were allowed inside parenthesis. 
This is exactly why we can’t have trailing commas. You are doing a function call without parenthesis so with trailing commas it’s ambiguous what the last argument is.
I hadn’t considered that.
However, it seems that the root cause of the ambiguity is that parentheses are optional. There’s nothing ambiguous about this, is there?
# syntax error
ArgsDemo.normal_args(
10,
"blue",
)
If there’s a closing parenthesis, couldn’t the parser notice that and ignore the trailing comma?
We should also strive to reduce the amount of ambiguity in the language
I totally agree. Making parentheses required for function calls would remove the ambiguity, at some (arguable) aesthetic cost.
Indeed, I’d have the parser only accept trailing commas if it is inside parenthesis, otherwise it’d be disallowed.
Indeed, I’d have the parser only accept trailing commas if it is inside parenthesis, otherwise it’d be disallowed.
Yes - or inside [].
Yes, that’s what we do inside brackets. But we don’t want to add it for function calls because, like I said earlier, we can’t support it for parenthesis-less functions and we feel it would be inconsistent and confusing to only support it for some function calls.
That would be a breaking change and would not possible until Elixir 2.0.
I’m not sure this topic is worth discussing any longer. I think everyone feels like the loss of the trailing comma is worth losing over losing optional parenthesis. I remember the backlash when elixir started warning about omitting parenthesis when piping and I’m fairly positive thats not something the community would be willing to trade.
I wonder why you would want trailing commas in function calls.
Functions in Elixir and Erlang are defined by their name and arity. A trailing comma in a function call seems to introduce unnecessary ambiguity when it comes to the arity of the called function.
Does foo(bar,) refer to foo/1 or foo/2 with the second parameter accidentally omitted?
Multi-line, especially useful for macro’s:
someMacro(
ModuleName,
a_very_long_argument_maybe_some_AST_for_the_macro,
or_maybe - a_set_of + math_that / needs_to * be_performed,
a: 1, # Or keyword list for those that like to use them without `[]`
b: 2,
c: 3,
)
Convoluted example, but it gets the point across. Plus it unifies the trailing comma syntax with [] and {} and %{} too, thus making things more consistent.
I’d never recommend a trailing comma in a single-liner, not in any of those.
But in this example, you’re still using the trailing comma for a keyword list and not for function parameters.