Re: Why can’t for-of be applied to iterators?

Andreas Rossberg rossberg at
Wed Jun 12 11:46:03 PDT 2013

On 12 June 2013 19:51, Brendan Eich <brendan at> wrote:
> The @iterator part of the iteration protocol is not about coercion or types
> at all. It is a "pattern" for getting or creating a usable iterator from an
> object.

You are entitled to call it what you think is best, of course, but in
the current state of affairs, implicit coercion is the only thing
@iterator actually gives you. Simple test: if you removed it from the
picture (in favour of for-of just accepting iterators) that would be
the only thing you'd lose.

On 12 June 2013 20:14, Brendan Eich <brendan at> wrote:
> Claude Pache wrote:
>> Le 12 juin 2013 à 18:14, Andreas Rossberg<rossberg at>  a écrit :
>>> On 12 June 2013 14:12, Claude Pache<claude.pache at>  wrote:
>>>> <snip>
>>>> On the other hand, I see a small advantage of the "weird" requirement
>>>> for iterators to be iterables themselves: It allows to discriminate between
>>>> true iterators and merely  "nextable" objects.
>>> And in the spirit of "duck typing", why would you want to do that?
>> Just so that an error is surely thrown in case I feed a for/of loop with a
>> non-iter{ator|able}. In the spirit of duck-typing, I consider that "having
>> an `@@iterator` method" is a more robust check than "having an `@@iterator`
>> or a `next` method". Not a big deal, however.
> I think it is a medium-sized deal :-).
> First, it's conceptually cleaner to have one symbol-named property test than
> two, symbol and then string name fallback.
> Second, it is indeed more robust in this instance: 'next' is a common name,
> with many contextual meanings and likely uses.

I am a bit surprised to see you on the opposite side of the "duck
typing" fence all of a sudden. ;)

>>> And
>>> how do you want to treat an iterable with a 'next' method, but whose
>>> @@iterator method does not return 'this'? Is that a "true" iterator?
>>> (The fact that such a beast can even exist shows how fuzzy those
>>> notions are.)
>> You're right, but I don't expect to encounter such a beast often.
>> Concretely, they are buggy objects that would not receive any special
>> treatment (they are iterable whenever an `@@iterator` method is expected,
>> and they are iterated whenever a `next` method is required).
> This just isn't a problem in practice. Let's solve real problems, look at
> cowpaths and nearby cliffs, not try to push boilerplate onto all programmers
> out of an off-target desire to make get- at iterator a "type coercion".

Huh? The suggestion in question _reduces_ boiler plate, namely the
need for every iterator to implement a braindead @@iterator method.
Nothing else changes in practical terms.


More information about the es-discuss mailing list