Trailing comma for function arguments and call parameters

Isiah Meadows impinball at gmail.com
Sun Jul 6 22:36:03 PDT 2014


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:
https://github.com/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)
> >>
> >>  Hence, i don’t think this should be extended to other constructs.
> >>
> >>  —Oliver
> >>  _______________________________________________
> >>  es-discuss mailing list
> >>  es-discuss at mozilla.org
> >>  https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140707/5c42b6df/attachment-0001.html>


More information about the es-discuss mailing list