I see. I always considered the last value to be a part of the iteration,
but if you don't (and for(of) treats it like that) it makes perfect sense.
Thanks!
Tim
On Tue, Jun 30, 2015 at 8: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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150630/9a1db70b/attachment.html>
d at domenic.me (2015-07-07T02:15:47.260Z)
I see. I always considered the last value to be a part of the iteration,
but if you don't (and for(of) treats it like that) it makes perfect sense.
I see. I always considered the last value to be a part of the iteration, but if you don't (and for(of) treats it like that) it makes perfect sense. Thanks! Tim On Tue, Jun 30, 2015 at 8: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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150630/9a1db70b/attachment.html>