Kevin Smith (2013-12-05T15:18:40.000Z)
TLDR:  We should consider deferring specialized syntax for exporting a
"default" binding until after ES6.

In the current draft, there are 3 ways to export a default binding:

1. Export a local binding with the name "default":

    class Parser { ... }
    export { Parser as default };

2.  Use "default" as a BindingIdentifier.  BindingIdentifer is
parameterized on [Default]:

    export class default { ... }

3. Use a "default" assignment:

    export default class { ... }; // AssignmentExpression

Methods 2 and 3 are inessential - they can be expressed in terms of 1.

Methods 2 and 3 are minor optimizations.  Method 1 is by no means painful
to write or read.

There are some potential downsides to providing methods 2 and 3:

- It may be that they provide too many ways to do the same thing, with too
little to differentiate them.
- Method 2 makes the grammar more complex, for parsers and (more
importantly) users.
- Method 3, being an assignment, introduces initialization-order
sensitivity that otherwise might be avoidable.
- They bind orthogonal issues:  On the one hand, the need to export a
default binding, and on the other, the need to reference a local binding
with some local name.

Proposal:  defer "default export" sugarings until ES7, when we can use data
gathered from experience with ES6 modules to guide syntax additions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131205/853bac8d/attachment.html>
domenic at domenicdenicola.com (2013-12-10T01:49:26.089Z)
TLDR:  We should consider deferring specialized syntax for exporting a
"default" binding until after ES6.

In the current draft, there are 3 ways to export a default binding:

1. Export a local binding with the name "default":

    ```js
    class Parser { ... }
    export { Parser as default };
    ```

2.  Use "default" as a BindingIdentifier.  BindingIdentifer is
parameterized on [Default]:

    ```js
    export class default { ... }
    ```

3. Use a "default" assignment:

    ```js
    export default class { ... }; // AssignmentExpression
    ```

Methods 2 and 3 are inessential - they can be expressed in terms of 1.

Methods 2 and 3 are minor optimizations.  Method 1 is by no means painful
to write or read.

There are some potential downsides to providing methods 2 and 3:

- It may be that they provide too many ways to do the same thing, with too
little to differentiate them.
- Method 2 makes the grammar more complex, for parsers and (more
importantly) users.
- Method 3, being an assignment, introduces initialization-order
sensitivity that otherwise might be avoidable.
- They bind orthogonal issues:  On the one hand, the need to export a
default binding, and on the other, the need to reference a local binding
with some local name.

Proposal:  defer "default export" sugarings until ES7, when we can use data
gathered from experience with ES6 modules to guide syntax additions.