github at esdiscuss.org (2013-07-12T02:27:20.808Z)
Allen Wirfs-Brock wrote:
> Note I didn't propose no `yield`s inside of `try`s, only no `yield`s in `try`s that include a `finally` clause.
Yes, I was saving typing :-/.
We've been over this at least twice. Let's get it right. No `close`, `yield`
in `try`-with-`finally` ok.
Merge `next` and `send` by letting `next` take an optional parameter? Ok by me.
Make `yield*` work on any `{next, throw}`, not necessary but ok by me too.
Are we there yet?
Allen Wirfs-Brock wrote: > On May 13, 2013, at 4:22 PM, Brendan Eich 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. > > Note I didn't propose no yield's inside of try's, only no yields in try's that include a finally clause. Yes, I was saving typing :-/. We've been over this at least twice. Let's get it right. No close, yield in try-with-finally ok. Merge next and send by letting next take an optional parameter? Ok by me. Make yield* work on any {next, throw}, not necessary but ok by me too. Are we there yet? /be