Quantcast

Strawman: Complete array and object destructuring

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strawman: Complete array and object destructuring

Paul Whipp
The ... destructuring for arrays is an excellent improvement that makes javascript code more readable and robust.

On seeing the syntax for the first time I expected to be able to use it more completely. For example:

```js
const [column, ...restOfColumns] = columns;
const objProps = column.valueChain.slice(0, -1);
const prop = column.valueChain[column.valueChain.length - 1];
//const [...objProps, prop] = column.valueChain
```

The commented out form `[...objProps, prop]` fails as per the spec, as would `[first, ...rest, last]` in spite of these being 'natural' uses that I believe a naive programmer (me at least ;)) would expect to work.

As can be seen in the example above, if more complete destructuring were supported, javascript code using it would be easier to read and write.

For objects, when the `...varName` is used on the LHS, I'd expect the varName to be assigned to a new object containing only those properties not extracted. In this case, as the order of keys in an object are arbitrary, the position of this element in the LHS would not matter. In addition to extracting properties from objects, this lets me have a shallow copy with `const {...copy} = source;` or to 'pop' a property with something like ` {[propName]: propValue, ...obj} = obj}`.

The object destructuring could be considered a separate proposal if necessary.

-- Paul Whipp

PS: First contemplated here

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

Re: Strawman: Complete array and object destructuring

Jordan Harband
The reason this doesn't work is because `...` in this context is not array destructuring - it's *iterable* destructuring. When you spread a string, you don't get each code unit, you get each code *point* - and similarly, you can spread any iterator, array or not, and collect items from it

Iterators can be infinite, and there's no way to communicate in advance of "done" how many items there will be. So `[...a, b]` might freeze the program, and `[a, ...b, c]` would only know that it could stop collecting items into `b` once `c` had been reached and the iterator exhausted.

Object rest/spread is already a stage 3 proposal: https://github.com/tc39/proposal-object-rest-spread

On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <[hidden email]> wrote:
The ... destructuring for arrays is an excellent improvement that makes javascript code more readable and robust.

On seeing the syntax for the first time I expected to be able to use it more completely. For example:

```js
const [column, ...restOfColumns] = columns;
const objProps = column.valueChain.slice(0, -1);
const prop = column.valueChain[column.valueChain.length - 1];
//const [...objProps, prop] = column.valueChain
```

The commented out form `[...objProps, prop]` fails as per the spec, as would `[first, ...rest, last]` in spite of these being 'natural' uses that I believe a naive programmer (me at least ;)) would expect to work.

As can be seen in the example above, if more complete destructuring were supported, javascript code using it would be easier to read and write.

For objects, when the `...varName` is used on the LHS, I'd expect the varName to be assigned to a new object containing only those properties not extracted. In this case, as the order of keys in an object are arbitrary, the position of this element in the LHS would not matter. In addition to extracting properties from objects, this lets me have a shallow copy with `const {...copy} = source;` or to 'pop' a property with something like ` {[propName]: propValue, ...obj} = obj}`.

The object destructuring could be considered a separate proposal if necessary.

-- Paul Whipp

PS: First contemplated here

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Strawman: Complete array and object destructuring

Paul Whipp
Thanks Jordan, as you describe iterable destructuring, it makes implementation sense.

The square brackets (and documentation eg: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) had me thinking of it as destructuring into an array and then mapping to the variables.

The current javascript behaviour with babel 6.5 does appear to convert the iterable into an array. It freezes if the iterable is inexhaustable:

```js  
const arr = ['A', 'B', 'C'];
const [arrA, arrB, ...restArr] = arr;
```

works as we expect whereas:

```js  
const iterArr = {};
iterArr[Symbol.iterator] = () => ({next: () => ({value: 'a', done: false})}); // never ending iterator
const [iterA, iterB, ...restIterArr] = iterArr;
```
freezes. Perhaps this is a result of implementors sharing my confusion.

So my suggestion remains that we view this as 'array destructuring' and complete it by allowing the `...` term to take any position in the array. The freezing with inexhaustible iterables would be a coding error.


On 29 March 2017 at 11:26, Jordan Harband <[hidden email]> wrote:
The reason this doesn't work is because `...` in this context is not array destructuring - it's *iterable* destructuring. When you spread a string, you don't get each code unit, you get each code *point* - and similarly, you can spread any iterator, array or not, and collect items from it

Iterators can be infinite, and there's no way to communicate in advance of "done" how many items there will be. So `[...a, b]` might freeze the program, and `[a, ...b, c]` would only know that it could stop collecting items into `b` once `c` had been reached and the iterator exhausted.

Object rest/spread is already a stage 3 proposal: https://github.com/tc39/proposal-object-rest-spread

On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <[hidden email]> wrote:
The ... destructuring for arrays is an excellent improvement that makes javascript code more readable and robust.

On seeing the syntax for the first time I expected to be able to use it more completely. For example:

```js
const [column, ...restOfColumns] = columns;
const objProps = column.valueChain.slice(0, -1);
const prop = column.valueChain[column.valueChain.length - 1];
//const [...objProps, prop] = column.valueChain
```

The commented out form `[...objProps, prop]` fails as per the spec, as would `[first, ...rest, last]` in spite of these being 'natural' uses that I believe a naive programmer (me at least ;)) would expect to work.

As can be seen in the example above, if more complete destructuring were supported, javascript code using it would be easier to read and write.

For objects, when the `...varName` is used on the LHS, I'd expect the varName to be assigned to a new object containing only those properties not extracted. In this case, as the order of keys in an object are arbitrary, the position of this element in the LHS would not matter. In addition to extracting properties from objects, this lets me have a shallow copy with `const {...copy} = source;` or to 'pop' a property with something like ` {[propName]: propValue, ...obj} = obj}`.

The object destructuring could be considered a separate proposal if necessary.

-- Paul Whipp

PS: First contemplated here

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Strawman: Complete array and object destructuring

James Browning
The conversion to array is correct according to the spec
(https://tc39.github.io/ecma262/#sec-runtime-semantics-iteratordestructuringassignmentevaluation
final part on `AssignmentRestElement`).

Given that I see absolutely no reason initial rest couldn't work,
middle would work alright too but does have a decision that would need
to be made about what should be consumed in what direction e.g.:

```js
const [a, ...b, c] = [1]
// Should 1 be assigned to a or c? Or both?
```

Personally I don't see this as a huge issue, I feel like it'd make the
most sense to assign `a` first then `c` then `b` would be whatever is
left over.

On 3/29/17, Paul Whipp <[hidden email]> wrote:

> Thanks Jordan, as you describe iterable destructuring, it makes
> implementation sense.
>
> The square brackets (and documentation eg:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
> had me thinking of it as destructuring into an array and then mapping to
> the variables.
>
> The current javascript behaviour with babel 6.5 does appear to convert the
> iterable into an array. It freezes if the iterable is inexhaustable:
>
> ```js
> const arr = ['A', 'B', 'C'];
> const [arrA, arrB, ...restArr] = arr;
> ```
>
> works as we expect whereas:
>
> ```js
> const iterArr = {};
> iterArr[Symbol.iterator] = () => ({next: () => ({value: 'a', done:
> false})}); // never ending iterator
> const [iterA, iterB, ...restIterArr] = iterArr;
> ```
> freezes. Perhaps this is a result of implementors sharing my confusion.
>
> So my suggestion remains that we view this as 'array destructuring' and
> complete it by allowing the `...` term to take any position in the array.
> The freezing with inexhaustible iterables would be a coding error.
>
>
> On 29 March 2017 at 11:26, Jordan Harband <[hidden email]> wrote:
>
>> The reason this doesn't work is because `...` in this context is not
>> array
>> destructuring - it's *iterable* destructuring. When you spread a string,
>> you don't get each code unit, you get each code *point* - and similarly,
>> you can spread any iterator, array or not, and collect items from it
>>
>> Iterators can be infinite, and there's no way to communicate in advance
>> of
>> "done" how many items there will be. So `[...a, b]` might freeze the
>> program, and `[a, ...b, c]` would only know that it could stop collecting
>> items into `b` once `c` had been reached and the iterator exhausted.
>>
>> Object rest/spread is already a stage 3 proposal: https://github.com/
>> tc39/proposal-object-rest-spread
>>
>> On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <[hidden email]> wrote:
>>
>>> The ... destructuring for arrays is an excellent improvement that makes
>>> javascript code more readable and robust.
>>>
>>> On seeing the syntax for the first time I expected to be able to use it
>>> more completely. For example:
>>>
>>> ```js
>>> const [column, ...restOfColumns] = columns;
>>> const objProps = column.valueChain.slice(0, -1);
>>> const prop = column.valueChain[column.valueChain.length - 1];
>>> //const [...objProps, prop] = column.valueChain
>>> ```
>>>
>>> The commented out form `[...objProps, prop]` fails as per the spec, as
>>> would `[first, ...rest, last]` in spite of these being 'natural' uses
>>> that
>>> I believe a naive programmer (me at least ;)) would expect to work.
>>>
>>> As can be seen in the example above, if more complete destructuring were
>>> supported, javascript code using it would be easier to read and write.
>>>
>>> For objects, when the `...varName` is used on the LHS, I'd expect the
>>> varName to be assigned to a new object containing only those properties
>>> not
>>> extracted. In this case, as the order of keys in an object are
>>> arbitrary,
>>> the position of this element in the LHS would not matter. In addition to
>>> extracting properties from objects, this lets me have a shallow copy
>>> with
>>> `const {...copy} = source;` or to 'pop' a property with something like `
>>> {[propName]: propValue, ...obj} = obj}`.
>>>
>>> The object destructuring could be considered a separate proposal if
>>> necessary.
>>>
>>> -- Paul Whipp
>>>
>>> PS: First contemplated here
>>> <http://stackoverflow.com/questions/43055518/why-cant-i-use-javascript-array-rest-destructuring-both-ways>
>>>
>>> _______________________________________________
>>> 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
|  
Report Content as Inappropriate

Re: Strawman: Complete array and object destructuring

Paul Whipp
I agree `const [a, ...b, c] = [1]` would then imply `a === 1`, `b === []`, `c === undefined`.

Being able to destructure from either end or even from both ends at the same time is complete and consistent. If the programmer tries to obtain the last value of an inexhaustible iterable it should be no surprise that the code freezes. How do we get this into the spec?

On 29 March 2017 at 20:39, James Browning <[hidden email]> wrote:
The conversion to array is correct according to the spec
(https://tc39.github.io/ecma262/#sec-runtime-semantics-iteratordestructuringassignmentevaluation
final part on `AssignmentRestElement`).

Given that I see absolutely no reason initial rest couldn't work,
middle would work alright too but does have a decision that would need
to be made about what should be consumed in what direction e.g.:

```js
const [a, ...b, c] = [1]
// Should 1 be assigned to a or c? Or both?
```

Personally I don't see this as a huge issue, I feel like it'd make the
most sense to assign `a` first then `c` then `b` would be whatever is
left over.

On 3/29/17, Paul Whipp <[hidden email]> wrote:
> Thanks Jordan, as you describe iterable destructuring, it makes
> implementation sense.
>
> The square brackets (and documentation eg:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
> had me thinking of it as destructuring into an array and then mapping to
> the variables.
>
> The current javascript behaviour with babel 6.5 does appear to convert the
> iterable into an array. It freezes if the iterable is inexhaustable:
>
> ```js
> const arr = ['A', 'B', 'C'];
> const [arrA, arrB, ...restArr] = arr;
> ```
>
> works as we expect whereas:
>
> ```js
> const iterArr = {};
> iterArr[Symbol.iterator] = () => ({next: () => ({value: 'a', done:
> false})}); // never ending iterator
> const [iterA, iterB, ...restIterArr] = iterArr;
> ```
> freezes. Perhaps this is a result of implementors sharing my confusion.
>
> So my suggestion remains that we view this as 'array destructuring' and
> complete it by allowing the `...` term to take any position in the array.
> The freezing with inexhaustible iterables would be a coding error.
>
>
> On 29 March 2017 at 11:26, Jordan Harband <[hidden email]> wrote:
>
>> The reason this doesn't work is because `...` in this context is not
>> array
>> destructuring - it's *iterable* destructuring. When you spread a string,
>> you don't get each code unit, you get each code *point* - and similarly,
>> you can spread any iterator, array or not, and collect items from it
>>
>> Iterators can be infinite, and there's no way to communicate in advance
>> of
>> "done" how many items there will be. So `[...a, b]` might freeze the
>> program, and `[a, ...b, c]` would only know that it could stop collecting
>> items into `b` once `c` had been reached and the iterator exhausted.
>>
>> Object rest/spread is already a stage 3 proposal: https://github.com/
>> tc39/proposal-object-rest-spread
>>
>> On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <[hidden email]> wrote:
>>
>>> The ... destructuring for arrays is an excellent improvement that makes
>>> javascript code more readable and robust.
>>>
>>> On seeing the syntax for the first time I expected to be able to use it
>>> more completely. For example:
>>>
>>> ```js
>>> const [column, ...restOfColumns] = columns;
>>> const objProps = column.valueChain.slice(0, -1);
>>> const prop = column.valueChain[column.valueChain.length - 1];
>>> //const [...objProps, prop] = column.valueChain
>>> ```
>>>
>>> The commented out form `[...objProps, prop]` fails as per the spec, as
>>> would `[first, ...rest, last]` in spite of these being 'natural' uses
>>> that
>>> I believe a naive programmer (me at least ;)) would expect to work.
>>>
>>> As can be seen in the example above, if more complete destructuring were
>>> supported, javascript code using it would be easier to read and write.
>>>
>>> For objects, when the `...varName` is used on the LHS, I'd expect the
>>> varName to be assigned to a new object containing only those properties
>>> not
>>> extracted. In this case, as the order of keys in an object are
>>> arbitrary,
>>> the position of this element in the LHS would not matter. In addition to
>>> extracting properties from objects, this lets me have a shallow copy
>>> with
>>> `const {...copy} = source;` or to 'pop' a property with something like `
>>> {[propName]: propValue, ...obj} = obj}`.
>>>
>>> The object destructuring could be considered a separate proposal if
>>> necessary.
>>>
>>> -- Paul Whipp
>>>
>>> PS: First contemplated here
>>> <http://stackoverflow.com/questions/43055518/why-cant-i-use-javascript-array-rest-destructuring-both-ways>
>>>
>>> _______________________________________________
>>> 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
|  
Report Content as Inappropriate

Re: Strawman: Complete array and object destructuring

Isiah Meadows-2
@implementors

Could you tell me whether I'm thinking on the right track for
implementing inner rest parameters? I know you all had serious
concerns over optimization of inner rest parameters initially (hence
why it didn't make it into ES2015), so I was wondering if this
addressed some of them, and what issues might crop up with this
particular case. Also, feel free to correct me on any misconceptions
and errors I made here.

-----

Here's how I feel additional non-rest parameters could be done, in a
single pass with support for arbitrary arguments length. It's
intentionally written low-level, with use of `goto`, so it's clearer
how it might be implemented. In particular, I specified the arguments
to be incrementally processed, for a bit of flexibility in calling.

- *argsIter* is an internal iterator over the arguments passed.
- *prefixes* is the list of prefixing bindings.
- *suffixes* is a list of suffixing bindings.
- *rest* is an optional binding for the rest parameter.
- The next value of *argsIter* is "nothing" if It's finished.

1. Let *p* be 0.
2. Let *pend* be the number of items in *prefixes*.
3. Repeat until *p* = *pend*:
  1. Let *value* be the next item in *argsIter*.
  2. If *value* is nothing, go to step 9.
  3. ! SetValue(*prefixes*[*p*], *value*).
  4. Set *p* to *p* + 1.
4. Let *s* be 0.
5. Set *send* to the number of items in *suffixes*.
6. Repeat until *i* = *send*:
  1. Let *value* be the next item in *argsIter*.
  2. If *value* is nothing, go to step 12.
  3. ! SetValue(*suffixes*[*s*], *value*).
  4. Set *s* to *s* + 1.
7. If *rest* is not nothing:
  1. Let *array* be ArrayCreate(0).
  2. Let *values* be an empty list.
  3. For each *ref* in *suffixes*:
    1. Append ! GetValue(*ref*) to *values*.
  4. Let *r* be 0.
  5. Repeat:
    1. Let *value* be the next item in *argsIter*.
    2. If *value* is nothing, break.
    3. Let *prev* be *values*[0].
    4. Remove *prev* from *values*.
    5. Append *value* to *values*.
    6. Let *status* be CreateDataProperty(*array*, ToString(*r*),
GetValue(*prev*)).
    5. Assert: *status* is true.
    6. Set *r* to *r* + 1.
  4. ! SetValue(*rest*, *array*).
8. Go to 14.
9. Repeat until *p* = *pend*:
  1. ! SetValue(*prefixes*[*p*], undefined).
  2. Set *p* to *p* + 1.
10. Set *s* be 0.
11. Set *send* be the number of items in *suffixes*.
12. Repeat until *s* = *send*:
  1. ! SetValue(*suffixes*[*s*], undefined).
  2. Set *s* to *s* + 1.
13. If *rest* is not nothing, ! SetValue(*rest*, «»).
14. Assert: all function parameters are initialized.

-----

Here's the benefits I see to this approach:

- It's all in a single pass with near-zero runtime allocation beyond
the array generation.
- *values* in step 7 can be implemented via using a fixed-length ring
buffer pre-allocated on bytecode compilation time.
- All "number of ..." things in the above algorithm are known after parse time.
- Most applicable optimization can trivially be done during bytecode
compilation.
- Very little runtime branching (as in, not known from counting during parsing).

So it's doable. It's just not trivial, considering this may likely
require adapting the calling convention in most engines.

-----

Isiah Meadows
[hidden email]


On Wed, Mar 29, 2017 at 4:15 PM, Paul Whipp <[hidden email]> wrote:

> I agree `const [a, ...b, c] = [1]` would then imply `a === 1`, `b === []`,
> `c === undefined`.
>
> Being able to destructure from either end or even from both ends at the same
> time is complete and consistent. If the programmer tries to obtain the last
> value of an inexhaustible iterable it should be no surprise that the code
> freezes. How do we get this into the spec?
>
> On 29 March 2017 at 20:39, James Browning <[hidden email]> wrote:
>>
>> The conversion to array is correct according to the spec
>>
>> (https://tc39.github.io/ecma262/#sec-runtime-semantics-iteratordestructuringassignmentevaluation
>> final part on `AssignmentRestElement`).
>>
>> Given that I see absolutely no reason initial rest couldn't work,
>> middle would work alright too but does have a decision that would need
>> to be made about what should be consumed in what direction e.g.:
>>
>> ```js
>> const [a, ...b, c] = [1]
>> // Should 1 be assigned to a or c? Or both?
>> ```
>>
>> Personally I don't see this as a huge issue, I feel like it'd make the
>> most sense to assign `a` first then `c` then `b` would be whatever is
>> left over.
>>
>> On 3/29/17, Paul Whipp <[hidden email]> wrote:
>> > Thanks Jordan, as you describe iterable destructuring, it makes
>> > implementation sense.
>> >
>> > The square brackets (and documentation eg:
>> >
>> > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
>> > had me thinking of it as destructuring into an array and then mapping to
>> > the variables.
>> >
>> > The current javascript behaviour with babel 6.5 does appear to convert
>> > the
>> > iterable into an array. It freezes if the iterable is inexhaustable:
>> >
>> > ```js
>> > const arr = ['A', 'B', 'C'];
>> > const [arrA, arrB, ...restArr] = arr;
>> > ```
>> >
>> > works as we expect whereas:
>> >
>> > ```js
>> > const iterArr = {};
>> > iterArr[Symbol.iterator] = () => ({next: () => ({value: 'a', done:
>> > false})}); // never ending iterator
>> > const [iterA, iterB, ...restIterArr] = iterArr;
>> > ```
>> > freezes. Perhaps this is a result of implementors sharing my confusion.
>> >
>> > So my suggestion remains that we view this as 'array destructuring' and
>> > complete it by allowing the `...` term to take any position in the
>> > array.
>> > The freezing with inexhaustible iterables would be a coding error.
>> >
>> >
>> > On 29 March 2017 at 11:26, Jordan Harband <[hidden email]> wrote:
>> >
>> >> The reason this doesn't work is because `...` in this context is not
>> >> array
>> >> destructuring - it's *iterable* destructuring. When you spread a
>> >> string,
>> >> you don't get each code unit, you get each code *point* - and
>> >> similarly,
>> >> you can spread any iterator, array or not, and collect items from it
>> >>
>> >> Iterators can be infinite, and there's no way to communicate in advance
>> >> of
>> >> "done" how many items there will be. So `[...a, b]` might freeze the
>> >> program, and `[a, ...b, c]` would only know that it could stop
>> >> collecting
>> >> items into `b` once `c` had been reached and the iterator exhausted.
>> >>
>> >> Object rest/spread is already a stage 3 proposal: https://github.com/
>> >> tc39/proposal-object-rest-spread
>> >>
>> >> On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <[hidden email]>
>> >> wrote:
>> >>
>> >>> The ... destructuring for arrays is an excellent improvement that
>> >>> makes
>> >>> javascript code more readable and robust.
>> >>>
>> >>> On seeing the syntax for the first time I expected to be able to use
>> >>> it
>> >>> more completely. For example:
>> >>>
>> >>> ```js
>> >>> const [column, ...restOfColumns] = columns;
>> >>> const objProps = column.valueChain.slice(0, -1);
>> >>> const prop = column.valueChain[column.valueChain.length - 1];
>> >>> //const [...objProps, prop] = column.valueChain
>> >>> ```
>> >>>
>> >>> The commented out form `[...objProps, prop]` fails as per the spec, as
>> >>> would `[first, ...rest, last]` in spite of these being 'natural' uses
>> >>> that
>> >>> I believe a naive programmer (me at least ;)) would expect to work.
>> >>>
>> >>> As can be seen in the example above, if more complete destructuring
>> >>> were
>> >>> supported, javascript code using it would be easier to read and write.
>> >>>
>> >>> For objects, when the `...varName` is used on the LHS, I'd expect the
>> >>> varName to be assigned to a new object containing only those
>> >>> properties
>> >>> not
>> >>> extracted. In this case, as the order of keys in an object are
>> >>> arbitrary,
>> >>> the position of this element in the LHS would not matter. In addition
>> >>> to
>> >>> extracting properties from objects, this lets me have a shallow copy
>> >>> with
>> >>> `const {...copy} = source;` or to 'pop' a property with something like
>> >>> `
>> >>> {[propName]: propValue, ...obj} = obj}`.
>> >>>
>> >>> The object destructuring could be considered a separate proposal if
>> >>> necessary.
>> >>>
>> >>> -- Paul Whipp
>> >>>
>> >>> PS: First contemplated here
>> >>>
>> >>> <http://stackoverflow.com/questions/43055518/why-cant-i-use-javascript-array-rest-destructuring-both-ways>
>> >>>
>> >>> _______________________________________________
>> >>> 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
Loading...