Nov 18 notes

Brendan Eich brendan at
Mon Nov 22 00:57:47 PST 2010

On Nov 22, 2010, at 12:49 AM, Peter van der Zee wrote:

> On Mon, Nov 22, 2010 at 8:37 AM, David Herman <dherman at> wrote:
> > for (var i : x) ...      // must be new iteration
> > for (var i : T : x) ...  // iteration again, but parsed how?
> > for (var i : T in x) ... // for-in with annotated var
> Bummer!
> I'm beginning to feel more strongly again that overloading for-in, as opposed to introducing yet another syntactic variant of `for', is the right way to go.
> <thought experiment>
> Imagine we made Harmony backwards-incompatible in the following way: for-in loops would *only* work on iterable objects, and would dynamically fail on non-iterable objects. So if you wanted the legacy keys behavior, you would have to explicitly call a `keys' library function.
> </thought experiment>
> If we're gonna go invent new keywords why not use the obvious?
> iterate (var x in y) ...

Did you read Dave's previous post, or mine? "We" are not going to go invent some new overlong non-reserved word. "for" is the right word.

One might try retasking "do" but it's ambiguous: do-while loops do not require braces (K&R style favors them even for one-liners but it's just a convention).

Dave's point about getting people to use one universal quantifying loop structure is good. If that loop syntax is not for-in, it will have to be something new that works even when there is no iterate trapping proxy. But that will just be a suckier version of the universal (enumerating if not custom-iterating) for-in from JS1.7.

So what good are we really doing by forking for-in into bastard children (the one we have, definitely a bastard -- I should know! :-/) and a new one with red hair?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list