Guards are now ready for discussion (was: Nov 18 notes)

Brendan Eich brendan at
Mon Nov 22 01:09:56 PST 2010

On Nov 22, 2010, at 1:03 AM, Peter van der Zee wrote:

> On Mon, Nov 22, 2010 at 9:43 AM, Brendan Eich <brendan at> wrote:
> On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:
>> On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich <brendan at> wrote:
>> The ML-ish solution, which is forward compatible, is to parenthesize:
>> let typedObj = { (prop1:type1): value1, (prop2:type2): value2, ... };
>> The parentheses hurt too, but only this case. And it still may win to annotate the entire ObjectLiteral sometimes, which would avoid (or move to one common guard-type definition) the property-wise annotation overhead. Comments?
>> I wouldn't want to introduce forced parens for the sake of disambiguation for the coder. I'd rather go with ::, # or @ ...
> Those are not all equally good, and you're again sacrificing the common case (especially with ::) where there's no need to parenthesize, for the uncommon case of property-wise type annotation in an object initialiser.
> Actually, one can use : just fine in an initialiser provided one or two colons are required per property initialiser. There's no need for :: or anything else except to avoid a confusing re-use of colon. Which is an issue, but :: doesn't exactly address it!
> As you noted yourself in the other thread, if iterators take on the syntax of `for (var x : y : z)`, the single colon for guards would introduce ambiguity. (And I believe "::" could fix that?)

First, I did not argue that there was a formal grammar ambiguity. There may not be, but it still is ugly and confusing.

Second, you're arguing backwards -- we do not have for (x : z) today, it is not obvious we should add it to the language, so it does not follow that we must use :: for type annotations. The precedent for : as type annotation punctuator is stronger than the precedent for :: in the same role; meanwhile, from E4X and AS3 and other old-ES4 offshoots, we have :: for namespace qualification (C++ has that too). So :: is just wrong all around.

Before reaching in a reactive way for @, let's slow down and consider what got us here: over-eager bikeshedding of : instead of "in" to try to split for-in into two loops, to make programmers prejudge whether they want enumeration or something potentially meta-programmable (but not necessarily -- we did not decide that for (x : z) fails if z is not a proxy with an iterate trap, and that doesn't make much sense).

So as dherman pointed out, we're really just trying to replace for-in with for-: as the new for-in. But if the syntax is ugly and confusion, if not ambiguous, and if the new form won't work in old browsers anyway, what good are we doing? Defending against someone porting or mixing JS code into Harmony context and having a for-in loop that expects string keys fail because it got Fibonacci numbers?


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

More information about the es-discuss mailing list