Array tail destructuring

Olivier Lalonde olalonde at gmail.com
Mon Oct 3 22:05:12 UTC 2016


> I think Olivier's point is that there is no way to know when you should
stop iterating in the case of `[...a]` either - hence the two cases are
equivalently problematic, if at all. Pulling the last element out *when*
the iteration stops is a different concern IMO which seems trivial to solve:

Correct.

> 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".

Yes, exactly. I'd understand the issue better if "a" had to be an arbitrary
iterable but AFAICT it's alway an array and the RHS iterable always needs
to be fully iterated regardless of whether "[...a, last]" syntax is
supported or not.


On Mon, Oct 3, 2016 at 2:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

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



-- 
- Oli

Oli Lalonde
http://www.syskall.com <-- connect with me!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161003/c1d1b683/attachment-0001.html>


More information about the es-discuss mailing list