Discuss
  • Trailing comma for function arguments and call parameters

Trailing comma for function arguments and call parameters

# Dmitry Soshnikov (11 years ago)

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

We have it for Array and Object initialisers, and people like using them for long lists with prediction of new items adding in the future:

var modes = [
  read,
  write,
];

var platforms = {
  web,
  canvas,
};

In a world-wide, all linters seems propose not to use trailing commas because of old IE bugs, when the length of an array is calculated incorrectly (the trailing comma is considered as a "hole" element):

[1,].lenght; // 2 in older IE, 1 per ES5 spec

However, we some transform level, it's easy to use trailing commas (they are just striped for IE), and people really like them, making an actual style guide to use them: not only for convenience of adding new items in the future, but to preserve better version control system's blame logs (e.g. git, etc).

So in out internal system with such transforms, people started to ask, whether we can have the same for function parameters and call arguments as well? We have this implemented for another language we use -- HACK (version of PHP), and it's also a style guide rule to use trailing comma there.

function register(
  login,
  name,
) { ... }

register(
  'John',
  'Doe',
);

I responded that we can just implement own internal extension just yet, since it's not standard, but thought -- whether ES will actually need it at standard level?

Thing to note: rest params. After the rest there should be no trailing comma in the function arguments list, but still can be in the call params.

Dmitry

# Oliver Hunt (11 years ago)

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

We have it for Array and Object initialisers, and people like using them for long lists with prediction of new items adding in the future:

var modes = [
  read,
  write,
];

var platforms = {
  web,
  canvas,
};

I suspect, but brendan could tell us otherwise, that the allowance of trailing commas is a result of a bug in the early early days of JS, which then got matched by the wonders of bug for bug compat, and so became necessary for web compatibility.

Also, i’m not sure that your intended uses is sufficiently compelling to justify non-backwards compatible syntax (i’m not against adding new syntax, i just feel that it needs to have substantial benefits)

Hence, i don’t think this should be extended to other constructs.

—Oliver

# Dmitry Soshnikov (11 years ago)

On Fri, Jul 4, 2014 at 9:33 AM, Oliver Hunt <oliver at apple.com> wrote:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

We have it for Array and Object initialisers, and people like using them for long lists with prediction of new items adding in the future:

var modes = [
  read,
  write,
];

var platforms = {
  web,
  canvas,
};

I suspect, but brendan could tell us otherwise, that the allowance of trailing commas is a result of a bug in the early early days of JS, which then got matched by the wonders of bug for bug compat, and so became necessary for web compatibility.

Yeah, as mentioned, it for a long time was considered as a bad practice because of inconsistency of implementations, and I have suspicions that this perception of "early design mistake" was dictated by exactly those inconsistencies, that made the feature useless and harmful. However, times have changed: with a build/transform step the feature is turned into a very useful one, and can safely be used across implementations, and e.g. in our code base is a de-facto standard (you'll have a lint warning if you forget the trailing comma -- by the described above reasons: better git blame, and convenience of future items adding).

Also, i’m not sure that your intended uses is sufficiently compelling to justify non-backwards compatible syntax (i’m not against adding new syntax, i just feel that it needs to have substantial benefits)

Hence, i don’t think this should be extended to other constructs.

At the same time, yes, I completely agree, that for the language itself, it's probably not good enough reason to extend the syntax. And still, for the language itself, globally, we'll still have inconsistency of trailing comma handling in legacy IE engines. So, yes, I think it's just better to implement as a local extension if will be needed just yet. Just wanted to bring it at least to double-check and clarify/confirm.

Dmitry

# Alex Kocharin (11 years ago)

Unless you use leading comma style, trailing commas are very good to have for anything that has variable amount of items/keys/arguments.

This is a classic example I use to show why JSON is a bad idea: npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6

I believe the same thing applies for javascript functions. If it was a bug in javascript, I wish for more such bugs really...

04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:

# Alex Kocharin (11 years ago)

In fact, how about the same syntax for arrays and function calls? With trailing commas and elisions?

So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?

06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:

# Brendan Eich (11 years ago)

Oliver Hunt wrote:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov<dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

We have it for Array and Object initialisers, and people like using them for long lists with prediction of new items adding in the future:

var modes = [
   read,
   write,
];

var platforms = {
   web,
   canvas,
};

I suspect, but brendan could tell us otherwise, that the allowance of trailing commas is a result of a bug in the_early_ early days of JS, which then got matched by the wonders of bug for bug compat, and so became necessary for web compatibility.

No, trailing commas in array and object literals were intentional, to ease maintenance (counterexample: ANSI and ISO C enum).

The requirement for two adjacent commas to make a hole in an array, unless the hole is at index 0 (in which case one comma obviously is the right number), follows. IE JScript had a notorious bug where one trailing comma in an array literal made a hole, but that's long fixed.

# Isiah Meadows (11 years ago)

My responses are inline.

From: Alex Kocharin <alex at kocharin.ru> To: Oliver Hunt <oliver at apple.com>, Dmitry Soshnikov <

dmitry.soshnikov at gmail.com>

Cc: es-discuss <es-discuss at mozilla.org> Date: Sun, 06 Jul 2014 12:07:09 +0400 Subject: Re: Trailing comma for function arguments and call parameters

In fact, how about the same syntax for arrays and function calls? With

trailing commas and elisions?

So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?

06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:

Unless you use leading comma style, trailing commas are very good to

have for anything that has variable amount of items/keys/arguments.

This is a classic example I use to show why JSON is a bad idea:

npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6

I believe the same thing applies for javascript functions. If it was a

bug in javascript, I wish for more such bugs really...

04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov <

dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function

arguments, and call parameters?

No, because of a few reasons.

  1. Array and object literals are usually adjusted far more often than function argument lists. This justifies the change for those, but not functions.

  2. Function statements usually don't have such long lists of arguments that such a thing would truly become useful. That is rare even in C, where you may have as many as 6 or 7 arguments for one function.

  3. Typical formatting for function declarations (excluding opening curly brace) in virtually every project using curly-brace languages are like the following:

// couple arguments
function foo(a, b, c) {
  // stuff...
}

// many arguments
function bar(a,
             b,
             c,
             d,
             e) {
  // stuff
}

This general arguments formatting makes it mildly useless.

We have it for Array and Object initialisers, and people like using

them for long lists with prediction of new items adding in the future:

var modes = [
  read,
  write,
];

var platforms = {
  web,
  canvas,
};

I suspect, but brendan could tell us otherwise, that the allowance of

trailing commas is a result of a bug in the early early days of JS, which then got matched by the wonders of bug for bug compat, and so became necessary for web compatibility.

In the case of the array literal, that was actually in the spec since at least ES3, with arrays such as [,,] being legal, in this case, an array of length 2 and zero entries.

With object literals, older versions of Internet Explorer were the only browsers that parsed object literals correctly in ES3. With every other browser incorrectly parsing them like arrays, the spec was changed to reflect that in ES5.

For reference, here's the array literal and object literal definitions for each (underscore = subscript, ". . " = indent):

(ES3 and ES5)

ArrayLiteral: . . [ Elision_opt ] . . [ ElementList ] . . [ ElementList , Elision_opt ]

ElementList: . . Elision_opt AssignmentExpression . . ElementList , Elision_opt . . AssignmentExpression

Elision: . . , . . Elision ,

(ES3)

ObjectLiteral: . . { } . . { PropertyNameAndValueList }

PropertyNameAndValueList: . . PropertyAssignment . . PropertyNameAndValueList , PropertyAssignment

(ES5, difference is in the last line of Object Literal)

ObjectLiteral: . . { } . . { PropertyNameAndValueList } . . { PropertyNameAndValueList , }

PropertyNameAndValueList: . . PropertyAssignment . . PropertyNameAndValueList , PropertyAssignment

Also, i’m not sure that your intended uses is sufficiently compelling

to justify non-backwards compatible syntax (i’m not against adding new syntax, i just feel that it needs to have substantial benefits)

# Dmitry Soshnikov (11 years ago)

On Sun, Jul 6, 2014 at 10:36 PM, Isiah Meadows <impinball at gmail.com> wrote:

My responses are inline.

From: Alex Kocharin <alex at kocharin.ru> To: Oliver Hunt <oliver at apple.com>, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> Cc: es-discuss <es-discuss at mozilla.org> Date: Sun, 06 Jul 2014 12:07:09 +0400 Subject: Re: Trailing comma for function arguments and call parameters

In fact, how about the same syntax for arrays and function calls? With trailing commas and elisions?

So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?

06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:

Unless you use leading comma style, trailing commas are very good to have for anything that has variable amount of items/keys/arguments.

This is a classic example I use to show why JSON is a bad idea: npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6

I believe the same thing applies for javascript functions. If it was a bug in javascript, I wish for more such bugs really...

04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

  1. Function statements usually don't have such long lists of arguments that such a thing would truly become useful. That is rare even in C, where you may have as many as 6 or 7 arguments for one function.

Yes, it's true, however, my use-case was based on 80-cols rule we use in our code-base. And with type annotations (especially type annotations with generics, when you have types like Map<string, IParamDefinition> $params,

etc) it can quickly become more than 80 cols, and our style-guide is to use each parameter on its own line, with a trailing comma for convenience of future adding that will preserve git blame logs if one doesn't need always append the comma on previous line, in case when adding a new parameter.

But again, I already think that for the language itself, it won't be super useful just yet, since backward-incompatible syntax won't allow using it anyways for a long amount of time, and not everyone has the build/transform step, that allows adopt this for older versions. That's said, a local extension seems the way to go for me.

Dmitry

# Jussi Kalliokoski (11 years ago)

On Tue, Jul 8, 2014 at 1:40 AM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com

wrote:

On Sun, Jul 6, 2014 at 10:36 PM, Isiah Meadows <impinball at gmail.com> wrote:

My responses are inline.

From: Alex Kocharin <alex at kocharin.ru> To: Oliver Hunt <oliver at apple.com>, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> Cc: es-discuss <es-discuss at mozilla.org> Date: Sun, 06 Jul 2014 12:07:09 +0400 Subject: Re: Trailing comma for function arguments and call parameters

In fact, how about the same syntax for arrays and function calls? With trailing commas and elisions?

So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?

06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:

Unless you use leading comma style, trailing commas are very good to have for anything that has variable amount of items/keys/arguments.

This is a classic example I use to show why JSON is a bad idea: npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6

I believe the same thing applies for javascript functions. If it was a bug in javascript, I wish for more such bugs really...

04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

  1. Function statements usually don't have such long lists of arguments that such a thing would truly become useful. That is rare even in C, where you may have as many as 6 or 7 arguments for one function.

Yes, it's true, however, my use-case was based on 80-cols rule we use in our code-base. And with type annotations (especially type annotations with generics, when you have types like Map<string, IParamDefinition> $params, etc) it can quickly become more than 80 cols, and our style-guide is to use each parameter on its own line, with a trailing comma for convenience of future adding that will preserve git blame logs if one doesn't need always append the comma on previous line, in case when adding a new parameter

Another example can be found by looking at pretty much any Angular-based codebase, due to the dependency injection.

+1 from me for this. Anything that makes changesets easier to contain makes me happier. I also think it'd be a nice for syntax consistency to support this.

# Peter van der Zee (11 years ago)

On Fri, Jul 4, 2014 at 12:52 AM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

Fwiw, it also makes sense in AMD, where the set of dependencies can grow and the desire to put every module on its own line becomes desirable. I tend to do it for the array since you can be consistent with the leading/trailing comma there, but not so much for the func args.

Allowing an "empty" comma after the param list could fix that. Also allowing one before for the "comma-first" people would be nice.

But again, I already think that for the language itself, it won't be super useful just yet, since backward-incompatible syntax won't allow using it anyways for a long amount of time

This argument doesn't hold for server side approaches like node, or build-step approaches like you use yourself.

Also, if you apply this argument to any new syntax the language never changes, for better or worse ;)

Anyways, +1 from me. I'm tired of irrelevant diff lines...

# Isiah Meadows (11 years ago)

On Tue, Jul 8, 2014 at 8:05 AM, Peter van der Zee <ecma at qfox.nl> wrote:

On Fri, Jul 4, 2014 at 12:52 AM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

Fwiw, it also makes sense in AMD, where the set of dependencies can grow and the desire to put every module on its own line becomes desirable. I tend to do it for the array since you can be consistent with the leading/trailing comma there, but not so much for the func args.

I'll rescind my statement with that (although I don't usually use AMD).

Allowing an "empty" comma after the param list could fix that. Also allowing one before for the "comma-first" people would be nice.

I didn't even know that was not possible.

# Dmitry Soshnikov (11 years ago)

On Mon, Jul 7, 2014 at 3:40 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com

wrote:

On Sun, Jul 6, 2014 at 10:36 PM, Isiah Meadows <impinball at gmail.com> wrote:

My responses are inline.

From: Alex Kocharin <alex at kocharin.ru> To: Oliver Hunt <oliver at apple.com>, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> Cc: es-discuss <es-discuss at mozilla.org> Date: Sun, 06 Jul 2014 12:07:09 +0400 Subject: Re: Trailing comma for function arguments and call parameters

In fact, how about the same syntax for arrays and function calls? With trailing commas and elisions?

So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ?

06.07.2014, 11:57, "Alex Kocharin" <alex at kocharin.ru>:

Unless you use leading comma style, trailing commas are very good to have for anything that has variable amount of items/keys/arguments.

This is a classic example I use to show why JSON is a bad idea: npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6

I believe the same thing applies for javascript functions. If it was a bug in javascript, I wish for more such bugs really...

04.07.2014, 20:33, "Oliver Hunt" <oliver at apple.com>:

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:

Hi,

Will it makes sense to standardize a trailing comma for function arguments, and call parameters?

  1. Function statements usually don't have such long lists of arguments that such a thing would truly become useful. That is rare even in C, where you may have as many as 6 or 7 arguments for one function.

Yes, it's true, however, my use-case was based on 80-cols rule we use in our code-base. And with type annotations (especially type annotations with generics, when you have types like Map<string, IParamDefinition> $params, etc) it can quickly become more than 80 cols, and our style-guide is to use each parameter on its own line, with a trailing comma for convenience of future adding that will preserve git blame logs if one doesn't need always append the comma on previous line, in case when adding a new parameter.

But again, I already think that for the language itself, it won't be super useful just yet, since backward-incompatible syntax won't allow using it anyways for a long amount of time, and not everyone has the build/transform step, that allows adopt this for older versions. That's said, a local extension seems the way to go for me.

Just received another the same question from developers: why don't we have trailing commas for function arguments, it's so convenient using them with arrays and objects, why not arguments?

So after rethinking it again -- will it still be interesting for ES7? (in this case implementing own extension will already be supported by a future standard).

Dmitry

# Dmitry Soshnikov (11 years ago)

OK, seems like it was added to agenda for the September meeting, glad to see that :) a discussion will help to clarify, whether JS needs it, or will it be too backward-incompatible.

Dmitr

# Rick Waldron (11 years ago)

Looking around and found this relevant thread: forum.dlang.org/thread/[email protected]