d at domenic.me (2015-07-07T02:15:26.084Z)
Kevin is right; I think the equivalence you're looking for is:
```js
var arrayIter = [1, 2, ..., n][Symbol.iterator]();
var genIter = (function*() { yield 1; yield 2; ... yield n; })();
```Kevin is right; I think the equivalence you're looking for is:
```js
var arrayIter = [1, 2, ..., n][Symbol.iterator]();
var genIter = (function*() { yield 1; yield 2; ... yield n; })();
```
Kevin is right; I think the equivalence you're looking for is: var arrayIter = [1, 2, ..., n][Symbol.iterator](); var genIter = (function*() { yield 1; yield 2; ... yield n; })(); On Tue, Jun 30, 2015 at 2:31 PM Kevin Smith <zenparsing at gmail.com> wrote: > If you use yield instead of return in your generator function you'll get > the desired results. When using a generator function to implement > iteration, you'll generally want to avoid returning a final value, since > for-of ignores the return value. > > The return value does have an important role to play in coroutine-style > use cases. > > On 2:20PM, Tue, Jun 30, 2015 Tim Jansen <ml at tjansen.de> wrote: > >> Hi, >> >> I am working on a collections library that supports the Iterable/Iterator >> protocol, but I ran into a stumbling block: the iterator protocol seems to >> work differently for arrays and generator functions. Array iterators set >> 'done' to true *after* the last element, but function generators set 'done' >> to true *on* the last element. >> >> Is this incompatibility intentional, or or just an implementation issue >> in the browsers (tested on FF38 and Chrome 43)? I wasn't able to find any >> information on this. The ES6 draft from April '15 doesn't define when >> exactly 'done' is set. >> >> >> Code example: >> >> var a = ['a', 'b']; >> >> var itA = a[Symbol.iterator]; >> >> itA.next(); // {value: 'a', done: false} >> >> itA.next(); // {value: 'b', done: false} !! >> >> itA.next(); // {value: undefined, done: true} >> >> >> function* b() { >> >> yield 'a'; >> >> return 'b'; >> >> } >> >> var itB = a[Symbol.iterator]; >> >> itB.next(); // {value: 'a', done: false} >> >> itB.next(); // {value: 'b', done: true} !!! >> >> itB.next(); // {value: undefined, done: true} >> >> The difference is in the second invocation of next(), which returns true >> for generator functions. That protocol makes it impossible for me to >> support both generator functions and array iterators with the same >> implementation - at least if I want to support 'undefined' as a valid value >> in collections. I wouldn't be able to differentiate between an empty list >> ([]) and a list containing undefined ([undefined]). >> >> >> Thanks, >> >> Tim >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150630/ecfed5f7/attachment.html>