Ignoring arguments

Kris Siegel krissiegel at gmail.com
Thu Aug 11 16:51:48 UTC 2016


>
> ignoring/skipping argument in functions declarations (indeed the
> invocations could be let apart)


I am of the opinion that this is not a problem that needs to be solved at
the language standardization level. The commas (or really any separator)
for "skipping" a parameter looks like a mistake and is unintuitive (it's
certainly not obvious to me what its intent is had I seen it without the
context of this thread).

This seems like a problem solved with better coding practices. I typically
make required parameters first and then any optional ones in a separate,
single parameter called options. Callbacks can be done with chaining /
promises / I fmake them required / etc. Skipping callbacks usually isn't a
good idea. We could talk all day about who's coding practice is better than
who's but ultimately this problem should be solved by developing / adopting
good coding practices.

(Honestly I'm not a fan of the skipping in arrays either but considering
it's an array I feel like it's at least a magnitude less confusing than
doing it with function parameters)

On Thu, Aug 11, 2016 at 4:00 AM, Cyril Auburtin <cyril.auburtin at gmail.com>
wrote:

> > Confused by this thread.
>
> It's quite simple though, _ would be a useless allocated variable, you
> an't have more than 1, ...
>
> > What is the problem that this proposal is trying to solve?
>
> ignoring/skipping argument in functions declarations (indeed the
> invocations could be let apart)
>
> > `Math.min(x,,y)`
>
> yes this kind of thing would give NaN, that's why you can `Math.min(x, ,
> y)` write it with more spaces to avoid a typo mistake, indeed you could
> still have like `Math.min(x, /*y (no longer used)*/ , z)` would. Like
> said above, I realize the function invocations are sensible.
>
> So, it would be only for function declarations
>
> `div.addEventListener('click', () => { } )` says to skip all arguments,
> and you've your callback scope is free of any additional vars
>
> `arr.forEach( x => { } )` says to only consider first argument, others are
> skipped, and not in scope
>
> `Array.from({length: 19}, (, i) => i )` would be similar for the second
> argument, similarly to array destructuring. It's not just for saving one
> character, that's really not the matter, it's for standardizing this way,
> because some people use `_`, some don't, ....
>
> 2016-08-10 16:27 GMT+02:00 Bob Myers <rtm at gol.com>:
>
>> Confused by this thread.
>>
>> > What if you could use a `.` as a wildcard?
>>
>> You can already use `_` or anything you want, as was already pointed out
>> in early iterations of this idea.
>>
>> > it would avoid binding a usable identifier.
>>
>> What is the problem with that?
>>
>> What is the problem that this proposal is trying to solve? Any chance we
>> could move on?
>>
>> Bob
>>
>>
>>
>> On Wed, Aug 10, 2016 at 7:48 PM, Alan Johnson <alan at breakrs.com> wrote:
>>
>>> What if you could use a `.` as a wildcard? I don’t think it would
>>> conflict with existing syntax, and it would avoid binding a usable
>>> identifier. It would be more obvious than nothing between the commas.
>>>
>>>
>>> On Aug 8, 2016, at 06:33, Cyril Auburtin <cyril.auburtin at 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.erratum at 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.auburtin at 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.erratum at 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 <rtm at 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.auburtin at 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 at mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss at mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> _______________________________________________
> 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/20160811/1a7448c8/attachment.html>


More information about the es-discuss mailing list