If we are talking about function definitions, It doesn't do exactly what a hole is supposed to do ``` [1,2,3,4].map((undefined, i)=>i) // undefined act as a variable [1,2,3,4].map((undefined, undefined, i)=>i) // so no ```
2016-08-12 4:04 GMT+02:00 J Decker <[email protected]>: > > > On Thu, Aug 11, 2016 at 5:55 PM, Cyril Auburtin <[email protected]> > 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 <[email protected]>: >> >>> 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 <[email protected]> wrote: >>> >>>> >>>> >>>> On Thu, Aug 11, 2016 at 1:28 PM, Isiah Meadows <[email protected]> >>>> 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 <[email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]>: >>>>>>> >>>>>>>> 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 <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>>> 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 <[email protected] >>>>>>>>> >: >>>>>>>>> >>>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>>>>>>>>>>> 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 <[email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> es-discuss mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> es-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> es-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> es-discuss mailing list >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
