FYI there's also some previous discussion on this here for those interested: https://mail.mozilla.org/pipermail/es-discuss/2015-October/044306.html https://esdiscuss.org/topic/rest-parameters
On Mon, Oct 3, 2016 at 3:05 PM, Olivier Lalonde <[email protected]> wrote: > > 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. <[email protected]> > wrote: > >> On Sun, Oct 2, 2016 at 2:11 AM, Caitlin Potter <[email protected]> >> wrote: >> > On Oct 2, 2016, at 10:50 AM, Awal Garg <[email protected]> wrote: >> >> On Oct 2, 2016, at 9:30 AM, Olivier Lalonde <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > - Oli > > Oli Lalonde > http://www.syskall.com <-- connect with me! > > _______________________________________________ > 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
