Strawman: Complete array and object destructuring

James Browning thejamesernator at gmail.com
Wed Mar 29 10:39:15 UTC 2017


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 <paul.whipp at gmail.com> 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 <ljharb at gmail.com> 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 <paul.whipp at gmail.com> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>


More information about the es-discuss mailing list