Strawman: Complete array and object destructuring

Paul Whipp paul.whipp at gmail.com
Wed Mar 29 20:15:51 UTC 2017


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 <thejamesernator at gmail.com> 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 <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
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170330/e4d1ea56/attachment-0001.html>


More information about the es-discuss mailing list