I see that the latest draft allows default to be used as a BindingIdentitifier in the context of an export. I don't see the value of this complication.
How is
export function default() {}
better than
export default function() {}
?
I presented the general solution here:
https://mail.mozilla.org/pipermail/es-discuss/2014-March/036697.html
Basic roadmap:
- eliminate `default` as a valid binding identifier name
- add special cases in the grammar for `export default` so that FunctionDeclaration, GeneratorDeclaration, and ClassDeclaration are legal as well as AssignmentExpression
- add a lookahead restriction to AssignmentExpression in this context to disambiguate in favor of the declaration forms
- this way the scoping rules place the name of the declaration in scope for the whole module, not just inside the expression, and the hoisting rules initialize the function early
One case that I neglected to mention in that email was anonymous function expressions, which need to be supported too, e.g.:
export default function() { };
So this needs a case in the grammar as well, and should also be initialized early just like the named function declaration. This is important to preserve the illusion that the RHS of export default is *always* an expression, even in the declaration cases (which are really only being called declarations for the purposes of scope). Indeed, existing ecosystems using ES6 already use this form, e.g.:
https://github.com/emberjs/ember.js/blob/4445be038bd839a1559020db5677b211dd3f1e9c/packages/ember-metal/tests/props_helper.js#L5
A couple possible ways to spec this:
- use a cover grammar for named vs anonymous functions
- add a new parameterization to FunctionDeclaration for "allowing anonymous declarations"
Dave
fixed in rev28 editor's draft.
Pretty much as Dave described. I parametrized FunctionDeclaration and GeneratorDeclaration for the situation in exports where the BindingIdentifer is optional.
*** Bug 2918 has been marked as a duplicate of this bug. ***
fixed in rev28