<div dir="ltr"><div>it matters when you have to debug/inherit *other* people's code (and clean up their mess).  i wouldn't enjoy debugging unfamiliar-code that used this feature (admittedly, its my subjective opinion).</div><div><br></div><div>the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.</div><div><br></div><div>debuggability is subjective i agree.</div><div><br></div><div>p.s. - in general, i don't see what *real* painpoint rest-operator actually address, that couldn't be solved with `arguments`.  variable-arg-length functions are not javascripty -- they frequently require extra ux-workflow transformations like Function.p.apply or Array.p.flatmap to the arguments being passed.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For your maintainability argument: adding extra arguments to those<br>
functions is something I almost never do. And you'd have the same<br>
exact issue with final rest parameters, just in a different position<br>
(in the middle as opposed to in the end).<br>
<br>
For debuggability, I don't see how it'd be a major issue unless you<br>
already have an excessive number of *positional* parameters. In my<br>
experience, the debuggability issues arise approximately when there's<br>
just too many positional parameters, and factoring out the rest<br>
parameter to an array doesn't really help this situation much. (That's<br>
when object destructuring comes in handy.)<br>
<br>
So not convinced either is any different than what it's like today.<br>
<br>
Also, you aren't obligated to use a feature just because it exists - I<br>
hardly ever use proxies, for instance, and I rarely need maps beyond<br>
what objects give me, so I don't normally use them unless I need to<br>
have reference types or mixed types as keys.<br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
On Thu, Jun 6, 2019 at 2:22 PM kai zhu <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br>
><br>
> -1 for maintainability and debuggability<br>
><br>
> 1. maintainability<br>
> if you want to extend the function with additional args,<br>
> then you'll have to retroactively modify all existing calls to avoid off-by-one argcount:<br>
><br>
> ```js<br>
> // if extending function with additional args<br>
> function pad(targetLength, ...opts, data) -><br>
> function pad(targetLength, ...opts, data, meta)<br>
><br>
> // then must retroactively append null/undefined to all existing calls<br>
> pad(1, opt1, opt2, "data") -><br>
> pad(1, opt1, opt2, "data", null)<br>
> ```<br>
><br>
><br>
><br>
> 2. debuggability<br>
> when debugging, it takes longer for human to figure out which arg is what:<br>
><br>
> ```js<br>
> // function pad(targetLength, ...opts, data)<br>
> pad(aa, bb, cc, dd);<br>
> pad(aa, bb, cc, dd, ee);<br>
><br>
> // vs<br>
><br>
> // function pad(targetLength, opts, data)<br>
> pad(aa, [bb, cc], dd);<br>
> pad(aa, [bb, cc, dd], ee);<br>
> ```<br>
><br>
><br>
><br>
> On Thu, Jun 6, 2019 at 11:54 AM Ethan Resnick <<a href="mailto:ethan.resnick@gmail.com" target="_blank">ethan.resnick@gmail.com</a>> wrote:<br>
>><br>
>> Long-time mostly-lurker on here. I deeply appreciate all the hard work that folks here put into JS.<br>
>><br>
>> 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:<br>
>><br>
>> ```<br>
>> const [...xs, y] = someArray;<br>
>> ```<br>
>><br>
>> Or, similarly, in function signatures:<br>
>><br>
>> ```<br>
>> function(...xs, y) { }<br>
>> ```<br>
>><br>
>> 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`.<br>
>><br>
>> 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:<br>
>><br>
>> ```<br>
>> function match(...matchersAndData) {<br>
>>   const matchers = matchersAndData.slice(0, -1);<br>
>>   const data = matchersAndData[matchersAndData.length - 1];<br>
>>   // do matching against data<br>
>> }<br>
>> ```<br>
>><br>
>> Under this proposal, the above could be rewritten:<br>
>><br>
>> ```<br>
>> function reduce(...matchers, data) { /* ... */ }<br>
>> ```<br>
>><br>
>> Another example: a function `pad`, which takes a target length and a string to pad, with an optional padding character argument in between:<br>
>><br>
>> ```<br>
>> function pad(targetLength, ...paddingCharAndOrData) {<br>
>>   const [paddingChar = " "] = paddingCharAndOrData.slice(0, -1);<br>
>>   const data = paddingCharAndOrData[paddingCharAndOrData.length - 1];<br>
>><br>
>>   // pad data with paddingChar to targetLength;<br>
>> }<br>
>> ```<br>
>><br>
>> With this proposal, that could be rewritten:<br>
>><br>
>> ```<br>
>> function pad(targetLength, ...opts, data) {<br>
>>   const [paddingChar = " "] = opts;<br>
>>   // pad data with paddingChar to targetLength;<br>
>> }<br>
>> ```<br>
>><br>
>> I'm curious if this has been considered before, and what people think of the idea.<br>
>><br>
>> 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.<br>
>><br>
>> Thanks<br>
>><br>
>> _______________________________________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>