On May 13, 2013, at 10:42 AM, Andreas Rossberg wrote:
> On 13 May 2013 17:58, Allen Wirfs-Brock <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
