On Apr 24, 2014, at 7:49 AM, Erik Arvidsson wrote: > I completely agree. Adding return() will make adoption suffer.
I don't think that should be the high order-bit on this decision. There are ways to implement finally unwinding that have zero to very low dynamic setup cost so there is only a significant cost when unwinding actually occurs. This would probably be a good thing for implementations to move towards. If (and it's still an open question) it make sense semantically to call "return" on for-of initiated generators on unwind, then that is what we should do. Implementations can catch up, but specified semantics is forever. Allen > > On Thursday, April 24, 2014 4:05:14 AM, Andreas Rossberg > <[email protected]> wrote: > On 15 April 2014 18:06, Allen Wirfs-Brock <[email protected]> wrote: > >>> AWB: We _could_ add a `return()` method. > >>> ... It's a bigger change, but we could make for-of invoke `return()` on > >>> exit > >>> or completion > >> > >> This would be a _significant_ cost. One reason we got rid of the > >> StopIteration protocol was the performance cost incurred by having to > >> wrap all loops into implicit try-statements, which are costly. This > >> proposal asks for re-introducing the same cost. > > > > Essentially it means that all generator based loops need to be wrapped in a > > finally. Whether or not this has a significant cost or is a equivalent to an > > exception handler depends upon implementation specific details of the > > runtime design. > > I'm very doubtful, given how VMs currently handle these features. I'm > pretty sure the consequence will be that the golden new future with > for-of and generators will be significantly slower than manual for-in > or for-;; loops for a long time, if not forever. And consequently, > adoption would suffer. > > And FWIW, it would have similar effects on yield* and generator > expressions as well. > > (We already see a similar effect with higher-order array functions: we > get regular complaints that they are slower than for-loops, but there > is only so much we can do given their more expensive spec'ed > semantics.) > > /Andreas > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
