Proposal: rest operator in middle of array

Isiah Meadows isiahmeadows at gmail.com
Fri Jun 7 15:07:21 UTC 2019


For your maintainability argument: adding extra arguments to those
functions is something I almost never do. And you'd have the same
exact issue with final rest parameters, just in a different position
(in the middle as opposed to in the end).

For debuggability, I don't see how it'd be a major issue unless you
already have an excessive number of *positional* parameters. In my
experience, the debuggability issues arise approximately when there's
just too many positional parameters, and factoring out the rest
parameter to an array doesn't really help this situation much. (That's
when object destructuring comes in handy.)

So not convinced either is any different than what it's like today.

Also, you aren't obligated to use a feature just because it exists - I
hardly ever use proxies, for instance, and I rarely need maps beyond
what objects give me, so I don't normally use them unless I need to
have reference types or mixed types as keys.

-----

Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <kaizhu256 at gmail.com> wrote:
>
> -1 for maintainability and debuggability
>
> 1. maintainability
> if you want to extend the function with additional args,
> then you'll have to retroactively modify all existing calls to avoid off-by-one argcount:
>
> ```js
> // if extending function with additional args
> function pad(targetLength, ...opts, data) ->
> function pad(targetLength, ...opts, data, meta)
>
> // then must retroactively append null/undefined to all existing calls
> pad(1, opt1, opt2, "data") ->
> pad(1, opt1, opt2, "data", null)
> ```
>
>
>
> 2. debuggability
> when debugging, it takes longer for human to figure out which arg is what:
>
> ```js
> // function pad(targetLength, ...opts, data)
> pad(aa, bb, cc, dd);
> pad(aa, bb, cc, dd, ee);
>
> // vs
>
> // function pad(targetLength, opts, data)
> pad(aa, [bb, cc], dd);
> pad(aa, [bb, cc, dd], ee);
> ```
>
>
>
> On Thu, Jun 6, 2019 at 11:54 AM Ethan Resnick <ethan.resnick at gmail.com> wrote:
>>
>> Long-time mostly-lurker on here. I deeply appreciate all the hard work that folks here put into JS.
>>
>> I've run into a couple cases now where it'd be convenient to use a rest operator at the beginning or middle of an array destructuring, as in:
>>
>> ```
>> const [...xs, y] = someArray;
>> ```
>>
>> Or, similarly, in function signatures:
>>
>> ```
>> function(...xs, y) { }
>> ```
>>
>> The semantics would be simple: exhaust the iterable to create the array of `xs`, like a standard rest operator would do, but then slice off the last item and put it in `y`.
>>
>> For example, I was working with some variable argument functions that, in FP style, always take their data last. So I had a function like this:
>>
>> ```
>> function match(...matchersAndData) {
>>   const matchers = matchersAndData.slice(0, -1);
>>   const data = matchersAndData[matchersAndData.length - 1];
>>   // do matching against data
>> }
>> ```
>>
>> Under this proposal, the above could be rewritten:
>>
>> ```
>> function reduce(...matchers, data) { /* ... */ }
>> ```
>>
>> Another example: a function `pad`, which takes a target length and a string to pad, with an optional padding character argument in between:
>>
>> ```
>> function pad(targetLength, ...paddingCharAndOrData) {
>>   const [paddingChar = " "] = paddingCharAndOrData.slice(0, -1);
>>   const data = paddingCharAndOrData[paddingCharAndOrData.length - 1];
>>
>>   // pad data with paddingChar to targetLength;
>> }
>> ```
>>
>> With this proposal, that could be rewritten:
>>
>> ```
>> function pad(targetLength, ...opts, data) {
>>   const [paddingChar = " "] = opts;
>>   // pad data with paddingChar to targetLength;
>> }
>> ```
>>
>> I'm curious if this has been considered before, and what people think of the idea.
>>
>> Obviously, if `...a` appeared at the beginning or middle of a list, there would have to be a fixed number of items following it, so a subsequent rest operator in the same list would not be allowed.
>>
>> Thanks
>>
>> _______________________________________________
>> 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


More information about the es-discuss mailing list