Proposal: rest operator in middle of array

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: rest operator in middle of array

Ethan Resnick
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

Andy Earnshaw-2
This has come up several times and, while it seems pretty intuitive to me, not everyone seems to agree. You can check the archives for previous discussions. 

On Thu, 6 Jun 2019, 17:54 Ethan Resnick, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

guest271314
In reply to this post by Ethan Resnick
```const [[...xs],] = someArray;```

On Thu, Jun 6, 2019 at 4:54 PM Ethan Resnick <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

kai zhu
In reply to this post by Ethan Resnick
-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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

kai zhu
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).

the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

debuggability is subjective i agree.

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.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <[hidden email]> wrote:
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

guest271314
its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

Appending extra arguments to a function is not an issue. A generator now be can be passed to a function  

```match(...gen())```

where the author should expect that subsequent arguments could affect previous arguments; which could, in general, be the purpose of appending the extra arguments.

From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the arguments to the function are a nested array of function calls? #1397.

The proposal appears to already be possible using existing JavaScript features. 

On Fri, Jun 7, 2019 at 5:11 PM kai zhu <[hidden email]> wrote:
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).

the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

debuggability is subjective i agree.

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.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <[hidden email]> wrote:
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

Ethan Resnick
In reply to this post by kai zhu
> This has come up several times and, while it seems pretty intuitive to me, not everyone seems to agree. You can check the archives for previous discussions. 

@Andy Perhaps you can provide some links? I found two threads — both 8 years old — that talked about this, along with one more recent one that didn't get very far. In the first two threads, commenters brought up one case where the semantics are unclear (i.e., when there are more listed binding elements than there are elements in the iterable), and there was some talk about implementation complexity. But there was also some interest from some big contributors to the spec. So I wonder if it's time to revisit this?

> 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:

@Kai I'm not sure I follow. If the new argument is required, you have to modify all existing calls whether the new argument goes at the end or as the second to last argument. If the new argument is optional, then adding it as the second to last argument doesn't break existing calls at all, assuming the function accounts for the fact that the optional arguments are all the ones after the initial required ones, and up until (but excluding) the last one. The syntax I'm proposing makes adding such extra arguments easy. In other words:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " "] = opts;
  // pad data with paddingChar to targetLength;
}
```

would, with the addition of an optional "meta" arg, become:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " ", meta = { /* some default */ }] = opts;
  // pad data with paddingChar to targetLength;
}
```

More importantly, though, this data-last calling pattern has a long history, and there are some cases where it's the best solution. My use case was similar to the common one, namely, that I was building a data pipeline, with the "settings" arguments partially applied from the left to create the function to use in each step. (And, in my case, I was building each function in a DSL where it would've been very inconvenient to add arbitrary-order partial application, even if JS were to add something like that.)

Given that functions where the last argument is significant probably aren't going away, it'd be nice imo if the JS syntax supported this better.

On Fri, Jun 7, 2019 at 7:11 PM kai zhu <[hidden email]> wrote:
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).

the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

debuggability is subjective i agree.

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.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <[hidden email]> wrote:
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

guest271314
The proposed pattern is already possible, as demostrated at the code at https://esdiscuss.org/topic/proposal-rest-operator-in-middle-of-array#content-2

How does the code at that post specifically not provide the same functionality as proposed?

On Mon, Jun 10, 2019 at 9:20 PM Ethan Resnick <[hidden email]> wrote:
> This has come up several times and, while it seems pretty intuitive to me, not everyone seems to agree. You can check the archives for previous discussions. 

@Andy Perhaps you can provide some links? I found two threads — both 8 years old — that talked about this, along with one more recent one that didn't get very far. In the first two threads, commenters brought up one case where the semantics are unclear (i.e., when there are more listed binding elements than there are elements in the iterable), and there was some talk about implementation complexity. But there was also some interest from some big contributors to the spec. So I wonder if it's time to revisit this?

> 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:

@Kai I'm not sure I follow. If the new argument is required, you have to modify all existing calls whether the new argument goes at the end or as the second to last argument. If the new argument is optional, then adding it as the second to last argument doesn't break existing calls at all, assuming the function accounts for the fact that the optional arguments are all the ones after the initial required ones, and up until (but excluding) the last one. The syntax I'm proposing makes adding such extra arguments easy. In other words:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " "] = opts;
  // pad data with paddingChar to targetLength;
}
```

would, with the addition of an optional "meta" arg, become:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " ", meta = { /* some default */ }] = opts;
  // pad data with paddingChar to targetLength;
}
```

More importantly, though, this data-last calling pattern has a long history, and there are some cases where it's the best solution. My use case was similar to the common one, namely, that I was building a data pipeline, with the "settings" arguments partially applied from the left to create the function to use in each step. (And, in my case, I was building each function in a DSL where it would've been very inconvenient to add arbitrary-order partial application, even if JS were to add something like that.)

Given that functions where the last argument is significant probably aren't going away, it'd be nice imo if the JS syntax supported this better.

On Fri, Jun 7, 2019 at 7:11 PM kai zhu <[hidden email]> wrote:
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).

the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

debuggability is subjective i agree.

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.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <[hidden email]> wrote:
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

guest271314
but imo it really masks the author's intention (in addition to being more verbose and less efficient) when compared to:
```
const [...xs, y] = someArray;
```

No intention is "masked". Yes, more verbose, though demonstrates that the expected output is now possible using current version of JavaScript. 

"less efficient" is a statement which requires evidence. Compared to what? How is "efficient" benchmarked and measured and compared? 

The proposed solutions for argument lists strike me as less-good. 

Again, the term "less-good" is entirely subjective. There is no "good" or "bad" code, there is only code. The opinion of "good" or "bad" is in the individual human mind, not the code, and is subject to change from one moment to the next. 


function match(matchers, data = matchers.pop()) {
  console.log(matchers, data);
}
const x = [[1,2],3];
match(x);
console.log(x); // [[1,2]], uh oh, x has changed.
```

As mentioned in the post, the same pattern as  ```const [[...xs], y = xs.pop()] = [someArray];``` can be used 

```
function match([...matchers], data = matchers.pop()) {
  console.log(matchers, data);
}
const x = [[1,2],3];
match(x);
console.log(x); // [[1,2]] no mutation
```

Each of the examples is already achievable using JavaScript shipped with the browser. Could not actually determine what the issue is with the existing code. It is already possible to compose code where the center, or any argument identifer can be spread to an array. If the input is individual arguments to a function, those arguments, too, can be converted to an array within the arguments scope; as it is possible to run functions in the argument scope which change the current and subsequent parameters. If the concept is dynamic and arbitrary arguments you can use object destructuring, default parameters, default values, ```Object.assign()```, or if necessary, a generator function.

On Mon, Jun 10, 2019 at 11:46 PM Ethan Resnick <[hidden email]> wrote:
> The proposed pattern is already possible, as demostrated at the code at https://esdiscuss.org/topic/proposal-rest-operator-in-middle-of-array#content-2

Sorry, I missed your response earlier!

Regarding

```
const [[...xs], y = xs.pop()] = [someArray];
```

That works and is quite clever, but imo it really masks the author's intention (in addition to being more verbose and less efficient) when compared to:

```
const [...xs, y] = someArray;
```

The proposed solutions for argument lists strike me as less-good. 

In the case of `pad`, using one, object-valued argument would make partial application impossible, which is essential in most data-last use cases. 

In the rewritten version of `match`, I'm not sure how the `pop()` trick is helping. If it's valid to pass in the matchers as a single, array-valued argument, then the signature can be simply:  `function match(matchers, data) { /* .. */ }`. The tricky bit about my original version was that it took the matchers passed in as separate arguments, rather than passing in a single array of matchers, for reasons that were more convenient in my domain.

I don't see how any version of the `pop()` trick can help when there are truly multiple optional arguments (a la the `opts` array in `pad`). Also, the `pop()` trick could be quite problematic if it ends up mutating the user's input, as it would in the given example:

```
function match(matchers, data = matchers.pop()) {
  console.log(matchers, data);
}

const x = [[1,2],3];
match(x);
console.log(x); // [[1,2]], uh oh, x has changed.
```


On Tue, Jun 11, 2019 at 1:13 AM guest271314 <[hidden email]> wrote:
The proposed pattern is already possible, as demostrated at the code at https://esdiscuss.org/topic/proposal-rest-operator-in-middle-of-array#content-2

How does the code at that post specifically not provide the same functionality as proposed?

On Mon, Jun 10, 2019 at 9:20 PM Ethan Resnick <[hidden email]> wrote:
> This has come up several times and, while it seems pretty intuitive to me, not everyone seems to agree. You can check the archives for previous discussions. 

@Andy Perhaps you can provide some links? I found two threads — both 8 years old — that talked about this, along with one more recent one that didn't get very far. In the first two threads, commenters brought up one case where the semantics are unclear (i.e., when there are more listed binding elements than there are elements in the iterable), and there was some talk about implementation complexity. But there was also some interest from some big contributors to the spec. So I wonder if it's time to revisit this?

> 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:

@Kai I'm not sure I follow. If the new argument is required, you have to modify all existing calls whether the new argument goes at the end or as the second to last argument. If the new argument is optional, then adding it as the second to last argument doesn't break existing calls at all, assuming the function accounts for the fact that the optional arguments are all the ones after the initial required ones, and up until (but excluding) the last one. The syntax I'm proposing makes adding such extra arguments easy. In other words:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " "] = opts;
  // pad data with paddingChar to targetLength;
}
```

would, with the addition of an optional "meta" arg, become:

```
function pad(targetLength, ...opts, data) {
  const [paddingChar = " ", meta = { /* some default */ }] = opts;
  // pad data with paddingChar to targetLength;
}
```

More importantly, though, this data-last calling pattern has a long history, and there are some cases where it's the best solution. My use case was similar to the common one, namely, that I was building a data pipeline, with the "settings" arguments partially applied from the left to create the function to use in each step. (And, in my case, I was building each function in a DSL where it would've been very inconvenient to add arbitrary-order partial application, even if JS were to add something like that.)

Given that functions where the last argument is significant probably aren't going away, it'd be nice imo if the JS syntax supported this better.

On Fri, Jun 7, 2019 at 7:11 PM kai zhu <[hidden email]> wrote:
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).

the maintainability argument stands -- its counter-intuitive in javascript that appending extra args to a function re-arranges arg-positioning and invalidates existing calls.

debuggability is subjective i agree.

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.


On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <[hidden email]> wrote:
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
[hidden email]
www.isiahmeadows.com

On Thu, Jun 6, 2019 at 2:22 PM kai zhu <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

Andy Earnshaw-2
In reply to this post by Ethan Resnick
On Mon, 10 Jun 2019 at 22:20, Ethan Resnick <[hidden email]> wrote:
@Andy Perhaps you can provide some links? I found two threads — both 8 years old — that talked about this, along with one more recent one that didn't get very far. In the first two threads, commenters brought up one case where the semantics are unclear (i.e., when there are more listed binding elements than there are elements in the iterable), and there was some talk about implementation complexity. But there was also some interest from some big contributors to the spec. So I wonder if it's time to revisit this?

Here's the one that I was involved in:


My comment was not meant to be dismissive, I was just hoping to provide some context (and I was on my mobile at the time). If several discussions have tailed off over the years without anyone making a concrete proposal, then it seems unlikely that this discussion will make any more progress than the ones before it. I think the real limiting factor is that this is not a burning issue for anyone, not a particular pain point in day to day programming, so there's no big appetite to try and overcome the main objections.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: rest operator in middle of array

guest271314
In reply to this post by Ethan Resnick
What are the complete expected input and output of ```match``` and ```pad``` functions?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss