April 10 2014 Meeting Notes

[Mark S. Miller]

Excellent. Given that, how realistic is the performance concern for the
non-exceptional situation? Where is the overhead?


On Thu, Apr 24, 2014 at 2:06 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Apr 24, 2014, at 12:38 PM, Mark S. Miller wrote:
>
> > I agree that this issue should treat for/of and [...x], etc, similarly.
> Either do both or neither.
> >
> > Does it alleviate the performance concerns if the .return is only
> invoked on early exit, i.e., before the iterator reports that it is done?
> For builtins like [...x], and for javascript code that has no statically
> apparent early exit, we'd know that the only remaining early exit
> possibility is a throw, which we already allow to be much slower.
>
> Mark, I'm quite convinced that it is only early exists (including
> exceptions originating within the loop) that need the @@return call. For
> any normal loop exist, the iterator will have reported {done: true} and it
> is the iterators responsibility to do the cleanup in that case.  If the
> iterator is a generator with a finally block to do the cleanup, the finally
> will have already been triggered by the return that produced the
> {done:true} result
>
> Allen
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140424/80f7d951/attachment.html>