Re: [webidl] Fix some problems with iterable declarations. (#72)

>                      <li><a href="#es-invoking-callback-functions">Invoke</a> <var>callback</var> with <var>thisArg</var>
>                        as the <a class="dfnref" href="#dfn-callback-this-value">callback this value</a> and
> -                      <var>k</var> and <var>value</var> as its arguments.</li>
> +                      <var>value</var>, <var>key</var> and <var>O</var> as its arguments.</li>
> +                    <li>Update <var>pairs</var> to the current list of <a class="dfnref" href="#dfn-value-pairs-to-iterate-over">value pairs to iterate over</a>.
> +                      <div class="note"><div class="noteHeader">Note</div>
> +                        <p>Depending on whether prose accompanying the interface defined this to be a snapshot at the time

With an index we can't even guarantee that an entry that was there before iteration starts will be iterated, if the right deletions happen.

For example, say our original list consists of the entries [0, 1, 2, 3, 4, 5] each number at itself as index.  We start iterating and in the callback with index == 3 delete entries 0, 1, 2.  At that point length == 3, so iteration is done and no callbacks happen for 4 and 5.

Map and Set go out of their way to avoid this with a specification device that can't be implemented in practice (removal never gives up memory) and some resulting implementation complexity.

Array has the behavior we have now: just use an index.  This is, of course, required because the Array stuff is trying to be generic and hence can't depend on tight cooperation with the thing being iterated.

We _could_ spec the Map/Set behavior for two-type iterables, I think, as follows: spec that the iterator object has a way to notify it on removal from the list (with the index the removal happened at) and if so notified will reduce its index if the removal happened before it.  Similar for insertions before the current index.  Prose for specific iterables would then have to define when (or whether) these notifications are delivered.  Maybe this is worth doing; that way the default behavior will be that there are no notfications so you get the Array iteration behavior but interfaces that want the Map/Set one can opt in to it without too much trouble.  I'm not sure we can make it any _easier_ to opt in to it than that.

I don't think we really want to support fully snapshotting here.  If people want that, they can define a way to produce an iterable snapshot as part of their interface.

---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/72/files#r44944553