Expression Closures in JS 1.8.1

Brendan Eich brendan at
Mon Aug 3 10:09:48 PDT 2009

On Aug 3, 2009, at 9:42 AM, Michael Haufe wrote:

> The documentation is a little sparse on the Mozilla page: 
> #Expression_closures
> and the wiki doesn't have a page created for it yet on the subject,  
> so I have a generic question on the grammar:
> Is their an ambiguity that prevents the following from being a valid  
> syntax?
> function foo();
> being the equivalent of
> function foo(){ return };

No, that's future proofing to allow for new meaning to be given to  
that new syntactic form. We require an expression, if only void 0 or  
undefined or 42:

function foo() void 0;

But for such a useless function, the shortest and best form is still:

function foo() {}

You don't need an explicit return with implicit undefined return  
value, if you don't need an explicit return value.

> Also, how is it that the following is not misinterpreted to  
> "function() { return false, true; }"?
> addEventListener("click", function() false, true)

The production is essentially

      function Identifier[opt] ( FormalParameterList[opt] )  

and an AssignmentExpression cannot produce an unparenthesized comma  

The JS1.8.1 expression closure grammar as implemented is buggy, as  
noted here:

Bottom-up grammar checking is part of the ECMA-262 standardization  
process (for Harmony by recent agreement, and it was for ES3; ES5 has  
no significant new syntax to check). The JS1.8.1 expression closure  
syntax will have to change, in order for it to be standardized.


More information about the es-discuss mailing list