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.
On Thu, Apr 24, 2014 at 12:30 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: es-discuss <es-discuss-boun...@mozilla.org> on behalf of Brendan
> Eich <bren...@mozilla.org>
>
> > No one is talking seriously about such a change.
>
> Why not? It seems like you'd want to perform any return-related "cleanup"
> just as clearly when you were doing `[...iterable]` or
> `Promise.all(iterable)`. What makes `for`-`of` special?
>
> Making the change only to `for`-`of`, and not all the other iterations in
> the spec, would preclude e.g. implementing `Promise.all` or `Array.from` in
> terms of `for`-`of`.
>
> Indeed, this seems related to other claims in the thread that, if
> `for`-`of` gets special-case `try { ... } finally { /* call return */ }`
> behavior, then people will be advised not to use `for`-`of`. Either because
> of a performance penalty, or because of the fact that it acts unlike every
> other iteration protocol use in the language and adds additional weird
> semantics.
>
> Am I missing something that makes the `for`-`of`--only modification more
> coherent?
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
