It all boils down to direct and indirect evaluation and static contextual
information. It can't be an identifier any more than super or this. It
can't be passed because it's a different type of evaluation that happens
relative to static context, in this case the containing module body.

You can pass access to it by closing over it however.

On Aug 5, 2017 11:47 AM, "Naveen Chawla" <> wrote:

Yes although it could be implemented like an object & function underneath
even if it's not officially exposed as one.

I think the key question is for interested TC39 members - whether passing
it around must be expressly disallowed or allowed. If allowed, `module` is
the only choice that won't go against the existing advice against
identifiers being keywords (besides being a more suitable name anyway). If
it must be expressly disallowed, `import` would be the compromise choice.

A use-case for passing it somewhere might be to a static helper function
which lives in another module, and which might use the `meta` information,
and which carries out the import whose parameter is based on some logic
that is repeated throughout the app.

Reasons for disallowing this must come from TC39 - till then I'm stumped

On Sat, 5 Aug 2017 at 19:10 T.J. Crowder <>

> On Sat, Aug 5, 2017 at 2:35 PM, Naveen Chawla <>
> wrote:
> >
> > Thanks for the link! That means that `import` is already on the
> borderline of the spec since it wants to be a function and object.
> No, not at all. It's a keyword. `import.meta` doesn't make `import` an
> object, any more than `` makes `new` an object.
> -- T.J. Crowder

es-discuss mailing list
es-discuss mailing list

Reply via email to