exports at the top of the file

Ben Newman benjamin at cs.stanford.edu
Tue Jun 7 14:37:36 UTC 2016


Is it possible that Crock meant export declarations should be restricted to
the *top level* of the file? In other words, they can't be nested in
conditional blocks or inside functions, but they can appear anywhere in the
outermost scope of the module?

If so, that's effectively what ECMAScript 2015 already requires:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-modules (note
that *StatementListItem* can never produce additional*ExportDeclaration*
symbols).

All export declarations define some number of exported symbol names
(even export
defaultdeclarations, where the name is "default"). Some export declarations
also declare local variables, functions, or classes, or evaluate default
expressions. It's important to keep in mind that the definition of exported
symbols is conceptually hoisted to the beginning of the module, while the
initialization of local entities happens wherever it normally would
(function declarations are also hoisted, but variables and classes are not,
and of course default expressions must be evaluated in their original
position, for the reasons mentioned by Logan S.).

In other words, for export declarations that *only* define exported symbols
(e.g. export { a, b as c }), it doesn't really matter where they appear in
the file, because (thanks to hoisting) it's as if you wrote them at the
beginning of the file, anyway.

That's my understanding, at least :)

Ben

On Tue, Jun 7, 2016 at 12:58 AM Logan Smyth <loganfsmyth at gmail.com> wrote:

> ```js
>> export default myConst;
>> const myConst = {};
>> ```
>> would throw because when the export is evaluated
>
>
> Correct, if you wanted to export `myConst` as the default without that
> issue, you'd want to do
>
> ```
> export {myConst as default};
> const myConst = {};
> ```
> to declaratively expose the binding under the default name, without
> requiring the value be available at the time.
>
> The key thing to remember with exports is that they are all processed
> before the JS has even begin executing, and as you saw, are no-ops at
> execution time, aside from `export default myConst` which is essentially
> sugar for
>
> ```
> const _hiddenBinding = myConst;
> export {_hiddenBinding as default};
> ```
>
> where the fact that a default binding exists is known at parse time. Only
> the value of the export is assigned at evaluation time.
>
> ```js
>> export {myConst};
>> const myConst = {};
>> ```
>
>
> This is not an issue. Export declarations define mappings of module-local
> binding names, to publicly exposed export names, and that is all, they do
> not access the value in any way on their own. It's possible that if you had
> some circular dependencies in your code, something could access `myConst`
> before it had been initialized, and that would result in a TDZ error the
> same way any other attempt to access the value would.
>
>
> On Mon, Jun 6, 2016 at 9:39 PM, Raul-Sebastian Mihăilă <
> raul.mihaila at gmail.com> wrote:
>
>> Douglas Crockford said that eventually JSLint would require exports at
>> the top of the file. However I think there are some issues.
>>
>> If my understanding is correct,
>>
>> ```js
>> export default myConst;
>> const myConst = {};
>> ```
>>
>> would throw because when the export is evaluated, in step 2 of the
>> Evaluation algorithm applied to the ExportDeclaration: export default
>> AssignmentExpression; production (
>> https://tc39.github.io/ecma262/#sec-exports-runtime-semantics-evaluation),
>> the value of the assignment expression is retrieved, which should cause an
>> error because the binding has not yet been initialized.
>>
>> I'm not sure what should happen if myConst was exported with an
>> ExportClause.
>>
>> ```js
>> export {myConst};
>> const myConst = {};
>> ```
>>
>> In this case, the Evaluation algorithm just returns a normal completion.
>> But I think that it depends on when myConst is indirectly accessed in the
>> importing modules. If it's accessed before `const myConst` is evaluated,
>> then I believe it would be uninitialized and would throw. Otherwise, it
>> would work.
>>
>> Is my understanding correct? Thanks!
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160607/22f9527a/attachment.html>


More information about the es-discuss mailing list