Ignoring arguments

Fri Aug 12 02:04:08 UTC 2016

On Thu, Aug 11, 2016 at 5:55 PM, Cyril Auburtin <cyril.auburtin at gmail.com>
wrote:

> > `( ( ignore_me, ignore_me2, asdf ) => { /* ... */ } ) (undefined,
> undefined, {whatever:1} )`
>
> Let's forget about functions invocations, a bad idea, so that's more the `ignore_me,
> ignore_me2` that are quite polluting/unpractical
>
> I'm not either a fan of skipping in arrays, but again function arguments
> is an array, that same syntax represent literally holes. there's also
> like for invocations the risks of a typo, but the coder has to be really
> distracted to not see it..
>
> Thanks for that discussion, it'll very likely never make it to the spec,
> and sorry my last message had typos, corrected on
> https://esdiscuss.org/topic/ignoring-arguments, mailing-lists :/
>
>
but the point of that really is... why can't you just use the token
'undefined' instead of trying to use whitespace?

> 2016-08-11 23:44 GMT+02:00 Michał Wadas <michalwadas at gmail.com>:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/54389519/attachment-0001.html>