Ignoring arguments

Thu Aug 11 21:44:53 UTC 2016

If you want to have new syntax for this feature, keyword void can be easily
reused:

((void, void, void, param)=>param)(1,2,3,4) // 4

But I don't think it's worth it.

On Thu, Aug 11, 2016 at 10:53 PM, J Decker <d3ck0r at gmail.com> wrote:

>
>
> On Thu, Aug 11, 2016 at 1:28 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> If you're talking about ignored function parameters in a declaration or
>> expression, much like `_` in several functional languages (like Haskell and
>> Scala), I could see value in that. I'd prefer an explicit token for that,
>> though, something like this:
>>
>
> 'undefined' is what, too many characters to type?
>
> ( ( ignore_me, ignore_me2, asdf ) => { /* ... */ } ) (undefined,
> undefined, {whatever:1} )
>
>
>
>
>> ```js
>>
> // ImmutableJS: convert map to list, only
>> // keeping values with integer keys
>> map
>> .filter((*, key) => typeof key === "number" && key % 1 === 0)
>> .toList()
>> ```
>>
>> On Thu, Aug 11, 2016, 12:51 Kris Siegel <krissiegel at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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/3cb286d9/attachment-0001.html>