Kevin Smith (2013-12-05T15:18:40.000Z)
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.