RE: What are the desired semantics of forEach for iterables?

From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> 1)  For two-type iterables, what should be passed as arguments to the callback function?  The obvious answer seems to be "value, key, this", with the index not passed at all.

Agreed.

> 2)  For one-type iterables, what should be passed as arguments to the callback function?  The two possible answers are "value, value, this" and "value, index, this"; the former matches Set and the latter matches Array.  The only one-type iterable I'm aware of shipping so far in browsers is DOMTokenList in Chrome, and this has the arraylike behavior, but it's also got an indexed getter so might be a special case anyway...

I think there is no good answer, and we will need a mechanism to allow either. My reasoning is:

- iterable<K, V> is useful for cases where something is kind of map-ish, but not properly maplike<K, V>. In particular, it is used for multimaps. I would expect iterable<T> to be useful for cases where something is kind of set-ish, but not properly setlike<T>. In this case, (value, value, this) is the desired behavior.
- However, iterable<T> is definitely useful for array-ish indexed objects, like NodeList. In that case (value, index, this) is correct.

Possible mechanisms of allowing both would be:

- Split the iterable declarations into something like arrayish_iterable<T>, setish_iterable<T> so the spec author chooses.
- Assume that if an indexed getter is present, the object is array-ish, so the (value, index, this) signature will be used. Otherwise assume it's set-ish, so use (value, value, this).

I admit though that the existence of set-ish but not setlike<> interfaces is speculation at this point. (Although, DOMTokenList...) So maybe we should just go with (value, index, this) always.

> 3)  How should deletion and addition during iteration, especially deletion be handled?  The two possible answers are:

I don't have a real opinion on this and would be happy to go with whatever's simpler to implement or results in a faster forEach method for authors.

Received on Saturday, 7 November 2015 09:08:43 UTC