Modules: Curly Free

David Herman dherman at
Tue Apr 16 09:55:20 PDT 2013

Hi Kevin,

Thanks, I do agree with most of your points, but it doesn't take into account anonymous export. I'm gonna bite the bullet here and tempt the bikeshedding demons by making an incremental suggestion for a syntax for anonymous import/export that adds to your syntax.

    export default f(1, 2, 3);        // creates anonymous export by evaluating RHS expression

    import default as foo from "foo"; // binds the anonymous export from module "foo" to variable foo

The downside of this is that it's a little chatty for what we expect to be the common case of modules with just a single export or modules where the vasty majority of the time you want the default export. But it has a nice symmetry and builds on your (valid) points.


On Apr 16, 2013, at 6:06 AM, Kevin Smith <zenparsing at> wrote:

> Currently, curly braces are used within import and export declarations:
>     import { something } from "url";
>     import { something: renamed } from "url";
>     import { a, b, c } from "url";
>     export { something };
>     export { renamed: something };
>     export { a, b, c };
> The import and export curlies are analogies for destructing and object literal syntax, respectively.  This analogy is problematic for the following reasons:
> 1) Destructuring declarations create new variables, whereas import declarations create aliases for existing variables.  This distinction is subtle and can lead to misunderstandings about module semantics.
> 2) Beginners tend to get the "direction" of renaming wrong with destructuring syntax:
>     let { myX: x } = { x: "value" }; // Oops!
> Since destructuring is an intermediate to advanced feature, it's not a big problem in that context.  But importing is one of the most basic features in the language.  We don't want to have a stumbling block right at the front door.
> 3) Curly braces within export declarations suggest a false semantics in which an object literal expression can be exported:
>     // Since is ok:
>     export { exportedA: a };
>     // It leads one to believe that this is ok:
>     export { exportedA: "some-value" };
> Given those considerations, I think we should find a curly-free syntax for import and export declarations.  Here is a proposal:
>     import something from "url";
>     import something as renamed from "url";
>     import a, b, c from "url";
>     export something;
>     export something as renamed;
>     export a, b, c;
> In the above syntax, "as" becomes the unified keyword for renaming module bindings.
> For an analysis of the ASI issues, see:
> { Kevin }
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list