On Nov 22, 2010, at 12:49 AM, Peter van der Zee wrote: > On Mon, Nov 22, 2010 at 8:37 AM, David Herman <dher...@mozilla.com> 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? /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
