HoistableDeclaration for export default function () {}

[caridy]

follow up from the discussion on jquery/esprima#311

after a quick look at the source, I don't see HoistableDeclaration.

I only see this:

    // export default ...;
    if (eat(_default)) {
      var expr = parseMaybeAssign();
      if (expr.id) {
        switch (expr.type) {
          case "FunctionExpression": expr.type = "FunctionDeclaration"; break;
          case "ClassExpression": expr.type = "ClassDeclaration"; break;
        }
      }

we are missing expr.type for HoistableDeclaration.

/cc @sebmck

[sebmck]

Isn't HoistableDeclaration a FunctionDeclaration?

[sebmck]

This is how the syntax is defined.

HoistableDeclaration[Yield, Default] :
FunctionDeclaration[?Yield,?Default]
GeneratorDeclaration[?Yield, ?Default]

And since there's no GeneratorDeclaration as it's just a generator property defined on a FunctionDeclaration it makes HoistableDeclaration equivalent, no?

[sebmck]

Ah right, you mean for anonymous functions. Does this really necessitate the addition of another node type when FunctionExpression is behaviourally equivalent in this context and can be reused?

[michaelficarra]

It'd be really unfortunate to introduce a new node type for that.

[sebmck]

@michaelficarra Agreed. Adds unnecessary complications for consumers.

[caridy]

no, it is not equivalent because FunctionExpression is not hoisted. I suspect that for the transpiler we can desugar this:

export default function () {}

to this:

function mod$default() {}
export {mod$default as default};

this is especially important if we are going do to any folding/bundling where the order of the definitions for the cycles is important.

[sebmck]

@caridy Yeah sure, but I'm arguing about representing it differently using an already existing construct.

[sebmck]

It'd be best to keep the discussion to jquery/esprima#311

[marijnh]

Given that HoistableDeclaration does not exist as a node type, I can see no reason for this issue to stay open.