Array tail destructuring
loganfsmyth at gmail.com
Tue Oct 4 02:40:40 UTC 2016
FYI there's also some previous discussion on this here for those
On Mon, Oct 3, 2016 at 3:05 PM, Olivier Lalonde <olalonde at gmail.com> 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:
> > 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>
>> On Sun, Oct 2, 2016 at 2:11 AM, Caitlin Potter <caitpotter88 at gmail.com>
>> > 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>
>> >>> So what's the problem with `[...a, last]` that `[...a]` doesn't have?
>> >>> still don't get it.
>> >> Since you don’t know when the iterator produced for `…a` will
>> >> there’s no way to know when you need to stop iterating `…a` and move
>> >> the next item `last`.
>> > That statement is factually incorrect. There is a simple criteria to
>> > when to terminate the iteration for a final rest element, which is when
>> > 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".
>> es-discuss mailing list
>> es-discuss at mozilla.org
> - Oli
> Oli Lalonde
> http://www.syskall.com <-- connect with me!
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss