Rule 317

liorean liorean at
Tue Oct 23 10:20:51 PDT 2007

> On Tue, 2007-10-23 at 14:58 +0200, liorean wrote:
> > It's there to prevent the grammar from being ambiguous. "function",
> > "let" and "{" have different meaning in statement context from
> > expression context. If the ExpressionStatement construct allowed them,
> > then they would be ambigous in statement context, they could have
> > either the statement or the expression semantics. So, in order to
> > prevent this ambiguity, they are not allowed in ExpressionStatement.

On 23/10/2007, David Teller <David.Teller at> wrote:
> So I guess this could just be handled by making this rule have a lowest
> priority ?

Not really. In statement context, a function without a name should be
a syntax error, it shouldn't be handled as function expression because
that'd be pointless. If the function object is only accessible through
the return value of the function expression but it's in statement
context - i.e. return values are thrown away - then compiling the
function at all is totally pointless, you're just adding a
non-reachable object for the garbage collector to deal with. In a
statement context, "{" is a block opener and not the beginning of an
object literal. In a block statement "Identifier :" is a label
statement and not a property assignment. "*string* :" is a syntax
error because ":" is not a valid operator there. (Not sure how type
annotations play into this, I might be wrong here...)

So you see, they can't just be lowest priority. They must fail with a
syntax error. For ES3 compatibility's sake, if nothing else. Also,
it's better to not let nonsensical constructs be allowed.
David "liorean" Andersson

More information about the Es4-discuss mailing list