Array tail destructuring

Tab Atkins Jr. jackalmage at gmail.com
Mon Oct 3 21:54:00 UTC 2016


On Sun, Oct 2, 2016 at 2:11 AM, Caitlin Potter <caitpotter88 at gmail.com> wrote:
> On Oct 2, 2016, at 10:50 AM, Awal Garg <awalgarg at gmail.com> wrote:
>> On Oct 2, 2016, at 9:30 AM, Olivier Lalonde <olalonde at gmail.com> wrote:
>>> So what's the problem with `[...a, last]` that `[...a]` doesn't have? I
>>> still don't get it.
>>
>> Since you don’t know when the iterator produced for `…a` will terminate,
>> there’s no way to know when you need to stop iterating `…a` and move onto
>> the next item `last`.
>
> That statement is factually incorrect. There is a simple criteria to know
> when to terminate the iteration for a final rest element, which is when the
> iterator returns a result object with "done": true.
>
> There is no condition to determine when to switch from a non-final rest
> element to some other element. That is a problem which needs to be
> addressed.

I'm similarly confused - there's no need to "determine when to
switch"; we don't evaluate things in different contexts or anything.
It just requires storage equal to the number of post-rest arguments;
when you do hit the end, the things you're holding onto get assigned
to the post-rest variable names.  This is all done internally with a
freshly-produced array; I don't *think* the timing of array-appending
is even observable, so you shouldn't be able to tell that an item is
appended only after later items are pulled from the source iterator.

I'm similarly confused by the wording you're using, tho, which
suggests there may be a deeper communication mismatch - there's no
"iterator produced for `...a`".  The ...a just indicates that you need
to pull on the iterator being assigned to the destructuring pattern,
and store the results that aren't claimed by other parts of the
destructuring pattern into "a".

~TJ


More information about the es-discuss mailing list