Strawman: Complete array and object destructuring

Isiah Meadows isiahmeadows at gmail.com
Thu Mar 30 10:51:48 UTC 2017


@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*:
  1. Let *value* be the next item in *argsIter*.
  2. If *value* is nothing, go to step 9.
  3. ! SetValue(*prefixes*[*p*], *value*).
  4. Set *p* to *p* + 1.
4. Let *s* be 0.
5. Set *send* to the number of items in *suffixes*.
6. Repeat until *i* = *send*:
  1. Let *value* be the next item in *argsIter*.
  2. If *value* is nothing, go to step 12.
  3. ! SetValue(*suffixes*[*s*], *value*).
  4. Set *s* to *s* + 1.
7. If *rest* is not nothing:
  1. Let *array* be ArrayCreate(0).
  2. Let *values* be an empty list.
  3. For each *ref* in *suffixes*:
    1. Append ! GetValue(*ref*) to *values*.
  4. Let *r* be 0.
  5. Repeat:
    1. Let *value* be the next item in *argsIter*.
    2. If *value* is nothing, break.
    3. Let *prev* be *values*[0].
    4. Remove *prev* from *values*.
    5. Append *value* to *values*.
    6. Let *status* be CreateDataProperty(*array*, ToString(*r*),
GetValue(*prev*)).
    5. Assert: *status* is true.
    6. Set *r* to *r* + 1.
  4. ! SetValue(*rest*, *array*).
8. Go to 14.
9. Repeat until *p* = *pend*:
  1. ! SetValue(*prefixes*[*p*], undefined).
  2. Set *p* to *p* + 1.
10. Set *s* be 0.
11. Set *send* be the number of items in *suffixes*.
12. Repeat until *s* = *send*:
  1. ! SetValue(*suffixes*[*s*], undefined).
  2. Set *s* to *s* + 1.
13. If *rest* is not nothing, ! SetValue(*rest*, «»).
14. 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


On Wed, Mar 29, 2017 at 4:15 PM, Paul Whipp <paul.whipp at gmail.com> wrote:
> 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
>> >>>
>> >>>
>> >>
>> >
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list