Allen Wirfs-Brock (2013-05-13T18:10:58.000Z)
On May 13, 2013, at 10:51 AM, Andy Wingo wrote:

> On Mon 13 May 2013 19:24, Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
> 
>> [yield* is] just a yielding loop over an iterator that for some reason
>> was arbitrarily being restricted to being a generator.
> 
> I don't think the restriction you mention was present in the harmony
> document, was it?

Not precisely, but its unconditional use of send/throw/close in that proposal precluded using any simple (only implements "next") iterator, including all of the built-in iterators.

> 
> For what it's worth:
> 
>> If I'm implementing an iterator via a generator and I have to perform
>> a inner-iteration over an contained iterable (for example, some sort
>> of flattening operation) the way I code that inner iteration shouldn't
>> depend upon whether or not the implementor of the inner iterable chose
>> to use a generator rather than a stateful object as the iterator.
> 
> +1
> 
>> First why do we need "send" at all.  Why not simply allow an argument to
>> be passed to "next" (of course, it is already allowed) and leave it up
>> to the generator implementation as to whether or not they pay any
>> attention to it.
> 
> +1
> 
>> That leaves only "throw" as an issue.  Personally, I'd just make it part
>> of the Iterator interface and provide an Iterator abstract class that
>> provides
>>   throw(exception) {throw exception}
>> as the default "throw" implementation so most iterator authors don't
>> even have to think about it.
> 
> +1
> 
> Regards,
> 
> Andy
>
github at esdiscuss.org (2013-07-12T02:27:23.483Z)
On May 13, 2013, at 10:51 AM, Andy Wingo wrote:

> On Mon 13 May 2013 19:24, Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
> 
>> [`yield*` is] just a yielding loop over an iterator that for some reason
>> was arbitrarily being restricted to being a generator.
> 
> I don't think the restriction you mention was present in the harmony
> document, was it?

Not precisely, but its unconditional use of `send`/`throw`/`close` in that proposal precluded using any simple (only implements `next`) iterator, including all of the built-in iterators.