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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
