function invocation with just commas for explicit undefined optional arguments in the middle

# manuelbarzi (22 days ago)

not sure if this proposal is/was already in discussion. didn't find it.

it's about having the chance to invoke a function with just commas where explicit undefined optional arguments at the beginning or in the middle (not the last one, so not to interfere with trailing commas developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas )

agree there's a convention to locate optional arguments at the end in general, but what if this possibility is accepted for exceptional cases where the order of arguments may infer in a function that alternates undefined optional values in its declaration.

so, for example, given a function:

function fun(a, b, c, d, e, f) { // optional c and e values }

apart from a regular invocation:

fun('a', 'b', undefined, 'd', undefined, 'f')

being able to invoke it with just commas where explicit undefined optional values:

fun('a', 'b',, 'd',, 'f')
# Tab Atkins Jr. (22 days ago)

On Tue, Oct 29, 2019 at 9:06 AM manuelbarzi <manuelbarzi at gmail.com> wrote:

fun('a', 'b',, 'd',, 'f')

While this does technically match up with arrays, I find the the array behavior unreadable and unintuitive (especially with the exception for the final comma), and I'd prefer that syntax quirk not spread to other list-like syntax constructs.

Passing undefined is simply and easy enough; if it's too long you can shave off three characters by spelling it void 0. Or put a var _; at the top of your script and use that.

# Naveen Chawla (21 days ago)

I tend to agree and one thing I like in good code is "glanceability" -

the ability to "glance" and see what's going on.

If I have

doStuff(bar,, foo,, far)

vs

doStuff(bar, foo,, far)

they don't look too different, but really they are. I normally break params into separate lines so I wouldn't have this problem, but there's the risk overall.

I like that a motivational factor for introducing a language feature is "reducing the likelihood of bugs", and in my mind this one seems to very slightly increase it

# Cyril Auburtin (21 days ago)

I proposed it a long time ago esdiscuss.org/topic/ignoring-arguments

but I agree with Tab Atkins nowadays, it would hurt readability

# Jeremy Martin (20 days ago)

I'm not sure I find the reduced readability argument compelling on this one. The alternatives suggested (throwaway variables or crowding meaningful parameters with undefined) don't get clean scores on that front either, IMO.

Simply eliding a parameter seems like a nice example of terse/expressive syntax. /2

# Cyril Auburtin (19 days ago)

yes true, it's even more annoying with eslint, you have to configure it with eslint.org/docs/rules/no-unused-vars#argsignorepattern for example

To be fair I considered this case mostly for Array.from({length: n}, (,i) => i), but it's easier to forget that comma. What's preferable is a whole

new syntax for ranges anyway (some people proposed tc39/proposal-slice-notation#32)

So in the end, having to ignore arguments is probably a sign of a 'bad' design, or at least other possible better workarounds

# Naveen Chawla (19 days ago)

Using undefined is readable, it's just not as short. But that's my point. Readability should normally trump "shortness" in case they conflict, in my mind, (while both are desirable) simply for the following reason: if something is accidentally misread, it can cause a bug when used or modified, which I think is worse than "having to type/read more". Of course, if a feature is both shorter and readable (e.g. ES6 classes, arrow functions, etc.) then I think it's an easier choice

# Boris Zbarsky (19 days ago)

On 11/1/19 5:10 AM, Cyril Auburtin wrote:

yes true, it's even more annoying with eslint, you have to configure it with eslint.org/docs/rules/no-unused-vars#argsignorepattern for example

That's talking about function declarations, whereas the original proposal in this thread is about function invocations.

To be fair I considered this case mostly for Array.from({length: n}, (,i) => i)

Right, that's a function declaration, not invocation.