For what it's worth, elided array elements aren't available in strict mode
(they're a syntax error), and it's not likely anyone is going to want to
add a new sloppy mode only feature. Plus, it's not easy to tell at a glance
if it's a typo or intentional. `Math.min(x,,y)` is a likely error, but a
syntax error is much more informative than `NaN` or a very odd `undefined`.
I don't see the point of not making it explicit.
On Mon, Aug 8, 2016, 06:34 Cyril Auburtin <cyril.aubur...@gmail.com> wrote:
> Just bumping this up
>
> Calling `foo(1)` where foo is defined with 3 arguments, lets the 2 others
> undefined, this behavior is already a bit magic and similar to the behavior
> of an array, so I still think foo(a,,b,,,c) should be like
> foo(...[a,,b,,,c])
>
> Other example:
> ```
> var m=new Map([[1], [2,], [3,7]]) // Map {1 => undefined, 2 => undefined,
> 3 => 7} // here commas fantasies are allowed in arrays
> m.set(3) // Map {1 => undefined, 2 => undefined, 3 => undefined} //
> setting implicitely value as undefined
> m.set(3, ) // not allowed, which should be m.set(...[3,])
> ```
>
> and again, it would help for callbacks too, `something( ( , , thirdArg) =>
> {} )`
>
> I saw this https://jeffmo.github.io/es-trailing-function-commas/, it
> seems like a sub-case
>
> 2016-05-29 23:07 GMT+02:00 Renki Ivanko <fatalis.erra...@gmail.com>:
>
>> One more similarity is that both function parameters and destructuring
>> allow default values: (foo = 1) vs [foo = 1].
>>
>>
>>
>> On Sun, May 29, 2016 at 11:56 PM, Cyril Auburtin <
>> cyril.aubur...@gmail.com> wrote:
>>
>>> Since functions arguments is an array under the hood, they could 'more
>>> behave the same'
>>>
>>> Both function arguments and arrays accept spreading: *[1, 2, ...args] *
>>> and *fn(1, 2, ...args)*
>>>
>>> a function definition like *(,i) => {}*, would be the equivalent of *var
>>> [,i] = arguments*
>>>
>>> an invocation *fn(,,i)* would be the equivalent of *[,,i]*
>>>
>>> It's possible with *(...[,i]) => {}, (_,i)=>{} *like Renki said, but
>>> slightly less simply
>>>
>>> Are there possible issues with that 'extension' of function syntax?
>>>
>>>
>>> 2016-05-29 21:32 GMT+02:00 Renki Ivanko <fatalis.erra...@gmail.com>:
>>>
>>>> You could stop with "rare"; having to make up unused names is an
>>>> obvious smell in comparison.
>>>>
>>>> ```js
>>>> foo(UNUSED1, UNUSED2, x)
>>>>
>>>> foo(_, __, x)
>>>>
>>>> foo(,, x)
>>>>
>>>> foo(...[,, x])
>>>> ```
>>>>
>>>> The latter is shorter and more explicit and would not be any more
>>>> confusing if it became common.
>>>>
>>>>
>>>> On Sun, May 29, 2016 at 8:46 PM, Bob Myers <r...@gol.com> wrote:
>>>>
>>>>> Eliding array elements is not "similar" to eliding function formal
>>>>> parameters. The latter is extremely rare, hardly readable, confusing,
>>>>> bug-prone, and unnecessary because there is already a "standard way" which
>>>>> is to use any old parameter name you want:
>>>>>
>>>>> ```js
>>>>> function foo(UNUSED1, UNUSED2, x)
>>>>> ````
>>>>>
>>>>> Most linters will not complain, or there are ways to shut them up if
>>>>> they do.
>>>>>
>>>>> If you want to throw away an argument, just throw it away.
>>>>>
>>>>> ```js
>>>>> function skipFirstParam(fn) { return ((first, ...args) =>
>>>>> fn(...args)); }
>>>>>
>>>>> `[1,2,3,4].map(skipFirstParam(i => i));
>>>>>
>>>>> ```
>>>>>
>>>>> Or use Renki's solution.
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>> On Sun, May 29, 2016 at 9:23 PM, Cyril Auburtin <
>>>>> cyril.aubur...@gmail.com> wrote:
>>>>>
>>>>>> Similarly to:
>>>>>>
>>>>>> `var [,x,,y] = [1,2,3,4,5,6];`
>>>>>>
>>>>>> I think it could be interesting to let a field empty in function
>>>>>> arguments
>>>>>>
>>>>>> `[1,2,3,4].map( (,i) => i )`, `Array.from({length:10}, (,i) => i )`
>>>>>>
>>>>>> `function test(a,,b) { }`
>>>>>>
>>>>>> (but that would alter the current parsing, that doesn't allow it)
>>>>>>
>>>>>> Currently I often use `_` as a way to mark ignored fields, but when
>>>>>> there are more than 1 you need another identifier. A standard way would
>>>>>> be
>>>>>> interesting rather
>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
