Editorial: Re-factor ExportSpecifier

[jugglinmike]

In prior editions, the ExportSpecifier production was defined using only
IdentifierName. However, when the ExportSpecifier is part of an "local"
ExportDeclaration, the IdentifierName was interpreted as an
IdentifierReference through an Early Error rule. The rule was
undesirable for a number of reasons:

• it duplicated the definition of IdentifierReference
• it relied on an abstract operation, ReferencedBindings, which was
  otherwise unused
• it was not technically necessary (a separate Early Error rule for
  ModuleBody requires that all ExportedBindings are declared within the
  module itself, and it is not possible to create a such a binding)

These details made interpreting ExportSpecifier difficult and tended to
obscure the motivation for the use of IdentifierName.

Re-factor ExportSpecifier with a production parameter describing whether
it belongs to a "local" or "indirect" ExportDeclaration. This allows for
the definition of dedicated grammar productions, obviating the need for
an explicit early error, and removing branching logic from the static
semantics rule ExportEntriesForModule. It also more clearly communicates
the intent behind related definitions of the production.

---

Note that while this patch improves a few aspects of the grammar, there is one
somewhat counterintuitive aspect that it does not address. Both ES2016 and this
modified version contain a use of "ExportEntriesForModule" where the "module"
value is "null". We could move the definitions for the "local" production into
"ExportEntries", but that would require additional considerations for
ExportsList. Maybe there's a better name for ExportEntriesForModule?

[littledan]

What do you think of this change, @GeorgNeis ?

[GeorgNeis]

I see the point, but I don't like that it introduces yet another grammar parameter. Can someone provide some background on why IdentifierName was used in the first place (rather than IdentifierReference)?

[jugglinmike]

My understanding is that IdentifierName is used so that imported namespaces
support the same property names as ordinary objects. For instance, compare:

var o = { if: 0 };
module.exports = o;

with:

var x;
export { x as if };

In both cases, the exported namespace object defines a property named if,
which consumers can access via o.if.

I agree that production parameters aren't perfect, but I do think it's
preferable to the abstract operation and "plain English" early error that we
have at the moment.

[bterlson]

Having reflected on this for a while I like it. I don't like adding grammar parameters willy-nilly but being able to understand the core semantics of this area simply by reading the grammar is a huge win.

Unless my read of the diff is wrong, this seems to be missing static semantics for ExportedNames?

[jugglinmike]

@bterlson Good catch. I've extended the definition of ExportedNames accordingly.

[jugglinmike]

@bterlson gh-692 introduced a minor conflict for this patch, so I resolved, rebased, and squashed (the original version is available here). Do you think this is ready to land? Or maybe I should find someone to bring it up at next week's meeting?

[bterlson]

@jugglinmike Sorry, I had to re-review. I don't think this needs consensus.

[jugglinmike]

Awesome, thanks Brian!