Strawman: Complete array and object destructuring

Paul Whipp paul.whipp at
Wed Mar 29 04:51:28 UTC 2017

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

The square brackets (and documentation eg:
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:

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

works as we expect whereas:

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> 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:
> tc39/proposal-object-rest-spread
> On Tue, Mar 28, 2017 at 5:55 PM, Paul Whipp <paul.whipp at> 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,, 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
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list