lexical for-in/for-of loose end

Brendan Eich brendan at mozilla.org
Wed Feb 1 15:31:32 PST 2012


Brendan Eich wrote:
> It's never inconsistent to allow one thing and disallow another. The 
> particulars matter. This isn't "anything goes". Destructuring has a 
> bit of utility and a lot of regularity in for-in head position. The 
> initialiser from VariableDeclarationNoIn has neither specific utility 
> nor regularity with respect to for-in in AWK, Python, or any other 
> language with such a construct. 

More to say, I sent too soon. Don't take this as more than it is: an 
attempt to explore an alternative meaning of for-in combined with 
certain destructuring patterns.

We have a request that seemed to receive popular support, to support

   for own (k in o) ...;

This could compose with the following nicely, and it tries to pave the 
CoffeeScript cowpath a bit (without taking CoffeeScript as normative or 
overriding or anything like that).

We could make just-so meanings for destructuring in for-in, also 
inspired by CoffeeScript (and JS1.7, which did this too while muddying 
the waters by failing to separate iteration protocol into for-of):

   for ([k, v] in o) ...;

Our current position is "use for-of and an items helper function":

   import items from "@reflect"; // currently @iter; could be part of 
standard prelude

   for ([k, v] of items(o)) ...;

But I think detailing the design of ES6 must be allowed to entertain an 
even easier-to-use extension to for-in.

If you want values not keys, then per the current proposal you use

   for (v of values(o)) ...;

given the necessary values import, or inclusion in a standard prelude.

There's a hole vs. CoffeeScript: we do not want for-of on a plain Object 
to iterate over enumerable property values. Arrays, yes, Objects, no -- 
no Object.prototype. at iterator. So no |for (v of o) ...| for o = {p:1, 
q:2, r:3}.

Also no for each (v in o) as E4X (ECMA-357) promulgated. SpiderMonkey 
and Rhino support it and probably will have to carry it, but such "each" 
does not say its meaning (values not keys) clearly, and it doesn't 
compose with "own" nicely.

But with destructuring for-in, you could write

   for ([, v] in o) ...;

This is a bit ugly (holes never look pretty, even when they're useful).

Not sure what I think of this but I thought I'd throw it out here on 
es-discuss. The reason I bring it up is twofold: 1) for own (k in o) 
still needs to be discussed; 2) the for ([k, v] of items(o)) ...; tax is 
a bit higher than I'd like.

/be


More information about the es-discuss mailing list