Array tail destructuring

Caitlin Potter caitpotter88 at gmail.com
Tue Oct 4 03:06:37 UTC 2016



> On Oct 3, 2016, at 10: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

"I'm similarly confused about your assertion that this idea needs to avoid a halting problem, because here's a way around this problem, not suggested by anyone else, with a non-negligible cost, so there"?

Really? I'm asking how they would alter IteratorBindingInitialization. It's not rocket science, but it's important for the discussion.


More information about the es-discuss mailing list