On May 13, 2013, at 10:42 AM, Andreas Rossberg wrote:

> On 13 May 2013 17:58, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> Every other place in the language (syntax and built-in functions) where we expect Iterables we transparently accept either iterator or generator objects.  Why should yield* be any different.
> 
> Generators are subtypes of iterators, but not the other way round. So
> it is to be expected that there are contexts where you can use the
> latter but not the former. And 'yield' is quite naturally a feature of
> generators.

But we are talking about yield* rather than yield.  It is completely irrelevant to yield* whether the inner iterator implements next/send via an direct method return or an encapsulated yield.


> 
> 
>> However, there is another alternative to close that addresses the finally issue.  I can make it statically illegal for a "yield" statement to be nested within a block that is protected by a "finally".  This preserve the integrity of "finally" which is my only concern.  It also address the for-of early exit issues. This restriction is trivial to specify (and should be only slightly less trivial to implement). Since I don't currently have "close" in the spec.  I probably should have done this anyway.
> 
> Yes, we had the same discussion in the V8 team the other week. It's a
> reasonable restriction, but it's also an ad-hoc restriction, which I'm
> personally not overly fond of. Moreover, there might be use cases
> where you control both definition and consumption of a generator, so
> that using finally might be safe and sensible. (On the other hand,
> there aren't really many meaningful use cases for finally to start
> with, so I don't worry too much about that.)
> 
> In short, I could live with that, but don't think it's necessary.

It closes down this whole edge-case focused discussion and that's valuable in itself.  Also, since it turns try {yield expr} finally{} into a syntax error  we could revisit the decision in a future edition if somebody actually comes up with compelling use cases.

I've alway made this trivial change to my working spec. draft.  If consensus prevails against it, its easy enough to undo, but for now I suggest we  move on with other issues.

Allen

On May 13, 2013, at 10:42 AM, Andreas Rossberg wrote:

> On 13 May 2013 17:58, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> Every other place in the language (syntax and built-in functions) where we expect Iterables we transparently accept either iterator or generator objects.  Why should yield* be any different.
> 
> Generators are subtypes of iterators, but not the other way round. So
> it is to be expected that there are contexts where you can use the
> latter but not the former. And 'yield' is quite naturally a feature of
> generators.

But we are talking about `yield*` rather than `yield`.  It is completely irrelevant to `yield*` whether the inner iterator implements `next`/`send` via an direct method return or an encapsulated `yield`.


>> However, there is another alternative to close that addresses the finally issue.  I can make it statically illegal for a `yield` statement to be nested within a block that is protected by a `finally`.  This preserve the integrity of `finally` which is my only concern.  It also address the `for`-`of` early exit issues. This restriction is trivial to specify (and should be only slightly less trivial to implement). Since I don't currently have `close` in the spec.  I probably should have done this anyway.
> 
> Yes, we had the same discussion in the V8 team the other week. It's a
> reasonable restriction, but it's also an ad-hoc restriction, which I'm
> personally not overly fond of. Moreover, there might be use cases
> where you control both definition and consumption of a generator, so
> that using finally might be safe and sensible. (On the other hand,
> there aren't really many meaningful use cases for finally to start
> with, so I don't worry too much about that.)
> 
> In short, I could live with that, but don't think it's necessary.

It closes down this whole edge-case focused discussion and that's valuable in itself.  Also, since it turns `try {yield expr} finally{}` into a syntax error  we could revisit the decision in a future edition if somebody actually comes up with compelling use cases.

I've alway made this trivial change to my working spec. draft.  If consensus prevails against it, its easy enough to undo, but for now I suggest we  move on with other issues.