>> One possibility is to add a space as apparently a few other languages do: >> >> for each (var i in x) >> >> Should be unambiguously parsable and easy to understand.
This has come up several times. For one, it's incompatible with ECMA-357 (E4X), which is implemented in SpiderMonkey and Rhino. But more importantly, IMO, the syntactic distinction between "for" and "for each" is not at all evocative of their semantic distinction. Indeed, "for" implicitly means "for each" already! >> Fair enough. Another important question is whether for..in should continue >> to guarantee that all values enumerated would be strings. A fair question, although as I believe Andreas pointed out earlier in the thread, it's subsumed by the more general question of whether for..in should continue to guarantee that all values enumerated would be keys. >> Preserving that guarantee clearly makes for..in useless for the >> strawman:iterators purpose, > > Why? The primary reason for the iterator protocol is avoiding eager > instantiation of the entire result set. If we force stringification in for-in > when used with an iterator, the protocol is still alive and well and useful. > > We could avoid stringification if next() is called on iterators directly, or > provide an additional distinct new for-each or whatever syntax that doesn't > stringify. IOW, we could usefully have: 1) only one for-in form, that is meta-programmable via iterate(), and that does not guarantee it only iterates over keys 2) two different forms: a) for-in, which is meta-programmable but where the semantics enforces the invariant that all values iterated over are keys; and b) another form (syntax TBD) which is meta-programmable but where the semantics does not modify the values iterated over Most of this discussion has been about #1 vs. #2, but it's good to point out that 2a is still compatible with a meta-programmable API. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
