Discuss
  • Strawman: Complete array and object destructuring

Strawman: Complete array and object destructuring

# Paul Whipp (8 years ago)

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:

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 stackoverflow.com/questions/43055518/why-cant-i-use-javascript-array-rest-destructuring-both-ways

# Jordan Harband (8 years ago)

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

# Paul Whipp (8 years ago)

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

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

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.

# James Browning (8 years ago)

The conversion to array is correct according to the spec (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.:

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.

# Paul Whipp (8 years ago)

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?

# Isiah Meadows (8 years ago)

@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:
  4. Let value be the next item in argsIter.
  5. If value is nothing, go to step 9.
  6. ! SetValue(prefixes[p], value).
  7. Set p to p + 1.
  8. Let s be 0.
  9. Set send to the number of items in suffixes.
  10. Repeat until i = send:
  11. Let value be the next item in argsIter.
  12. If value is nothing, go to step 12.
  13. ! SetValue(suffixes[s], value).
  14. Set s to s + 1.
  15. If rest is not nothing:
  16. Let array be ArrayCreate(0).
  17. Let values be an empty list.
  18. For each ref in suffixes:
  19. Append ! GetValue(ref) to values.
  20. Let r be 0.
  21. Repeat:
  22. Let value be the next item in argsIter.
  23. If value is nothing, break.
  24. Let prev be values[0].
  25. Remove prev from values.
  26. Append value to values.
  27. Let status be CreateDataProperty(array, ToString(r), GetValue(prev)).
  28. Assert: status is true.
  29. Set r to r + 1.
  30. ! SetValue(rest, array).
  31. Go to 14.
  32. Repeat until p = pend:
  33. ! SetValue(prefixes[p], undefined).
  34. Set p to p + 1.
  35. Set s be 0.
  36. Set send be the number of items in suffixes.
  37. Repeat until s = send:
  38. ! SetValue(suffixes[s], undefined).
  39. Set s to s + 1.
  40. If rest is not nothing, ! SetValue(rest, «»).
  41. 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 me at isiahmeadows.com