On Aug 10, 2015, at 1:35 AM, Jordan Harband wrote: > I interpreted this spec text (and the included generator code example) to > mean that the first "next" is the thing that determines the keys to be > enumerated - since the generator function body (including the Reflect.ownKeys > call) is not executed until that point.
The generator-based definition was intended to only be an informative example of a conforming enumeration algorithm. Anything it does that goes beyond requirements stated in the normative prose should not be considered a normative requirement. The deferral of all setup processing to the first `next` call is simply an artifact of the how generators works. > > The question was also raised on that linked bug, why does the spec leave > behavior undefined for keys added during enumeration? It seems like the spec > should either dictate that added keys are *not* enumerated, or, that they are > *always* enumerated. See my previous reply. When decisions about for-in were made for ES6, TC39 was not yet ready to try to mandate a normative enumeration order or other historically unspecified for-in semantic details. This could be reconsider in a future edition. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
