Erik Arvidsson (2013-05-14T00:03:59.000Z)
I'm also reluctant to ban yield + finally.

yield* should work with any iterable. It is conceptually the same as using
a for-of. If we can afford the call to get the iterator in for-of we can
surely afford it in yeild*.

+1 to merge next and send. I don't care about the name.

+1 to getting rid of close.


On Mon, May 13, 2013 at 7:22 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Allen Wirfs-Brock wrote:
>
>> In my response to Andy I concluded that syntactically restricting yield
>> to not be finally protected is the better solution.
>>
>
> It's a shame we have to around the block again. This was discussed over
> six years ago, when we were prototyping for ES4 and studying Python 2.5.
> Python started with that restriction and got rid of. So did we for ES4,
> prototyped in SpiderMonkey and Rhino.
>
> But the rationale based on finally being a strong guarantee is just
> broken. No such guarantee, so no need for 'close'.
>
> However (on top of a "But"), dropping close doesn't mean we should ban
> yield in try.
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130513/1046cafb/attachment.html>
github at esdiscuss.org (2013-07-12T02:27:23.471Z)
I'm also reluctant to ban `yield` + `finally`.

`yield*` should work with any iterable. It is conceptually the same as using
a `for`-`of`. If we can afford the call to get the iterator in `for`-`of` we can
surely afford it in `yield*`.

+1 to merge `next` and `send`. I don't care about the name.

+1 to getting rid of `close`.