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

Allen Wirfs-Brock allen at
Wed Jun 12 09:37:48 PDT 2013

Personally, I don't really think about  what is going on here as a type coercion  but I have no problem if you what to explain it as applying ToIterator.  It may even be useful to use this in the spec.

The Iterator and Iterable interfaces that I currently have defined in the draft are not really used in a normative manner  anywhere but I think they are a convenient short hand.  Iterable is just shorthand for "has a @@iterator method".  Iterator just means "has a "next" method that returns a iteration result object".  Some objects are both an Iterable and an Iterator.  I think of "throw" as part of the generator interface and yield as expecting either an iterable, an iterator or a generator as an argument.

To me the only substantive question we have on the table is whether "ToIterator" is defined as
       return the result of Invoke(obj,@@iterator,())

          if obj has @@iterator return the result of Invoke(obj,@@iterator,())
          else return obj

The spec. draft currently uses the equivalent of the first in for-of.  I think changing it to the second would be fine.


On Jun 12, 2013, at 3:55 AM, Andreas Rossberg wrote:

> On 11 June 2013 21:19, Brendan Eich <brendan at> wrote:
>> Andreas Rossberg wrote:
>>> That makes a terrible API, though. I think Axel has a valid point that
>>> the distinction between iterators and iterables is fuzzy enough to be
>>> more confusing and error-prone than useful.
>> Have you actually used Python or JS1.7 much, though?
>> Have to ask, since throwing "confusing" and "error-prone" charges demands
>> evidence or at least anecdotes.
> It is confusing me, for one -- I don't really understand the
> difference anymore, nor the intended use cases. Granted, I might be
> the only one confused. I'm not ready to believe that, though. ;)
> You see, initially the iterator proposals tried to suggest a simple
> and understandable model: iterators were objects with a 'next' method,
> iterables were objects with an @@iterator method that produces an
> iterator. But neither is true anymore:
> - Iterators are iterables, they are supposed to have a 'next',
> optionally a 'throw', and an @@iterator method that returns itself.
> That is, the iterator interface has become considerably more
> complicated and is mutually intertwined with iterables.
> - Iterables are iterators most of the time, except when they aren't.
> Their @@iterator method may produce a new iterator or, in most cases,
> not. That is, there is no useful contract of what an iterable is, and
> it is useless as a concept to implement abstractions against.
> Nevertheless, people will probably try, and then build something that
> does not reliably work for all iterables. Thus error-prone.
> Where things stand now, the only reason we have @@iterator at all is
> as a hook to provide implicit user-defined conversions from objects to
> iterators, invoked by the for-of loop (and by extension, yield*).
> We could simplify spec _and_ programmers' life by explicitly
> recognizing it as such. That is, for-of invokes a ToIterator
> conversion meta function, which is the identity for any 'nextable',
> and tries to invoke @@iterator for others. Thereby drop the misleading
> notion of iterable, and drop the weird requirement for iterators to be
> iterables themselves.
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list