Allow trailing commas in function calls

A lot of the development I’ve done across a variety of teams as well as my own personal projects revolves around formatting data in tables. Trailing commas in tables are acceptable by the interpreter, and I think this is a good thing.

Often I’ll want to format function calls in multiple lines. For example,

local output = string.format(
	"This is a very long format string with at least %d formats that have a %s and a %s. There's a %4.2f chance of something or other.",
	someNumber,
	someString,
	someOtherString,
	someFloat
)

I think this is a pretty reasonable way to write a longer function call. However, the lack of a comma on the end of someFloat really bugs me. Ultimately, yes, this is a low priority aesthetic request. I acknowledge that. But just let me put my pretty commas where they, in my mind, belong, please.

11 Likes

I’ve found the need for this feature before; usually while refactoring code I might change the order of an argument or two in VSCode, and try to Alt + Arrow Key to move the arguments at the call site quickly. Without a trailing comma, this becomes a syntax error that I need to navigate to and fix.

Apart from minor annoyances, I also work on tooling that sometimes generates Luau automatically, and find it annoying to have to special-case the output of a comma based on which argument I am generating. Example:

for i = 1, num_argument do
    output(argument[i])

    if i ~= num_argument then output(',') end
end
1 Like

Most linters I’ve used would auto-format your line like so instead of trailing comma:

local output = string.format(
	"This is a very long format string with at least %d formats that have a %s and a %s. There's a %4.2f chance of something or other.",
	someNumber,
	someString,
	someOtherString,
	someFloat)

I don’t think trailing comma makes sense because you are not adding elements to function calls as frequently as you would tables.

The idea behind the trailing comma is to reduce unnecessary diff lines as you work and commit on the files. Having a -1 and +1 in a table context is annoying to read the diff off compared to just a +1, but for a function call you are modifying the behavior of the function, so this is not harmful here for readability.

1 Like

I find that code you posted to be really ugly, so I guess I disagree with the linters you use. As for the diff stuff you mentioned, sure, it’s more commonly used on tables. As I said before, it’s an aesthetic preference and I just want to be able to make code that I think looks pretty. I don’t find it problematic because it doesn’t matter to those that don’t care, they can continue with their ugly parentheses format like you posted and never see the difference. But my eyes… my eyes will finally be free.

2 Likes