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 <[email protected]>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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
