>
> #2 was removed at the hallway discussion of the face to face meeting. Do
>> you still think we should remove #3?
>>
>>
>
After thinking about it a little more, I think deferring #3 might be best
after all.  Let's assume that the syntax is `export default =
AssignmentExpression`.  And further, let's assume that when a default
export is specified, it will almost invariably be a function or class.  If
so, then #3 will almost always be inferior to #1.

Consider the following module cycle, where the modules are arranged in
their execution order:

    // A.js
    import b from "B.js";
    b(); // Error: b has not been initialized

    // B.js
    import {} from "A.js";
    function b() {}
    export default = b;

    // main.js
    import {} from "B.js";

I believe that this will fail, because the local binding "b" in "A.js" has
not been initialized yet.  However, using #1 it works just fine:

    // A.js
    import b from "B.js";
    b(); // OK

    // B.js
    import {} from "A.js";
    function b() {}
    export { b as default };

    // main.js
    import {} from "B.js";

The aesthetic advantage of #3 over #1 is arguable at best, so it appears
that the only way in which #3 is justified is when the exported value is
*actually constructed at runtime*.  At this time, it's not clear to me that
this is anything but a rare edge case.  If ES6 usage patterns prove
otherwise, then a case can be built for adding syntax in ES7.

Thanks for hearing me out!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131207/201fdc7d/attachment.html>

> \#2 was removed at the hallway discussion of the face to face meeting. Do you still think we should remove #3?

After thinking about it a little more, I think deferring #3 might be best
after all.  Let's assume that the syntax is `export default =
AssignmentExpression`.  And further, let's assume that when a default
export is specified, it will almost invariably be a function or class.  If
so, then #3 will almost always be inferior to #1.

Consider the following module cycle, where the modules are arranged in
their execution order:

    // A.js
    import b from "B.js";
    b(); // Error: b has not been initialized

    // B.js
    import {} from "A.js";
    function b() {}
    export default = b;

    // main.js
    import {} from "B.js";

I believe that this will fail, because the local binding "b" in "A.js" has
not been initialized yet.  However, using #1 it works just fine:

    // A.js
    import b from "B.js";
    b(); // OK

    // B.js
    import {} from "A.js";
    function b() {}
    export { b as default };

    // main.js
    import {} from "B.js";

The aesthetic advantage of #3 over #1 is arguable at best, so it appears
that the only way in which #3 is justified is when the exported value is
*actually constructed at runtime*.  At this time, it's not clear to me that
this is anything but a rare edge case.  If ES6 usage patterns prove
otherwise, then a case can be built for adding syntax in ES7.

Thanks for hearing me out!