import.meta and TC39 process as a whole

Dmitrii Dimandt dmitrii at
Sat Aug 5 16:25:10 UTC 2017

Introduced in ECMASCRIPT 2015: Reflect is a built-in object that provides methods for interceptable JavaScript operations. 

Introduced in ECMASCRIPT 2015: The Symbol() function returns a value of type symbol, has static properties that expose several members of built-in objects, has static methods that expose the global symbol registry, and resembles a built-in object class but is incomplete as a constructor because it does not support the syntax "new Symbol()”. 

ECMAScript 5 introduced: yield, let

ECMASCRIPT 6 introduced: await as a reserved word in module code

So, introducting new things into the language is not really such a big problem as it’s made out to be ;)

What TC39 has opted to do though is this (quoting myself):

- keywords that look like objects (because they have additional properties) which are not objects (new with

- keywords that look like functions (because they are invoked like functions and return values like functions) which are not functions (import)

- keywords that look like objects *and* functions but are neither (import)

I’ll add another one: overloading of existing keywords with new meanings, semantics and behaviour in different contexts.

The proposal thus is an easy one: stop doing that :) Move system-related functionality to System. Make it special. Move module-related functionality to Module. Move introspection-related functionality to Introspect. Easy-peasy ;)

On Sat, 05 Aug 2017 at 18:14 Matthew Robb

mailto:Matthew Robb <matthewwrobb at>
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

Yes super is a keyword and had been reserved for a long time. I don't necessarily disagree with your premise about introducing new keywords that aren't reserved but the current tc39 policy on this is to not due to the high likelihood that it breaks current user code.

This conversation could go very different if that policy were amended and if you think you have a way to do this that doesn't break existing user code I would suggest submitting that as a proposal.

On Aug 5, 2017 12:08 PM, "Dmitrii Dimandt" <
mailto:dmitrii at
> wrote:

That’s not what I was really aiming at :)

The original concern was “to get ‘module’ : 1. It's a context-sensitive keyword, and code that's using it needs to 

be updated when migrated to a module. “

I was just pointing out that ‘import’ is already a context-sensitive keyword (as are a bunch of others, like super. Is super a keyword BTW?)

On Sat, 05 Aug 2017 at 18:03 Matthew Robb

mailto:Matthew+Robb+%3Cmatthewwrobb at
> wrote:

Ah but you can do:

export function meta(key) {

return import.meta[key]:


On Aug 5, 2017 11:59 AM, "Dmitrii Dimandt" <
mailto:dmitrii at
> wrote:

Import is already made to be a context-sensitive keyword

I don’t think you can have a

function x() {

   import {x} from ‘module’;


On Sat, 05 Aug 2017 at 13:07 "T.J. Crowder"


">"T.J. Crowder"

> wrote:

On Sat, Aug 5, 2017 at 11:58 AM, Naveen Chawla

mailto:naveen.chwl at
> wrote:


> How is `document` and `window` handled when someone does

> `const document =` ?

At global scope in a script body, in a browser context, it's an error,

as you presumably know, because `document` is already declared.

> It would seem perfectly fine to allow `module` to be masked by

> other variables, and if someone wants to use the module-global

> `module`, they can just rename in order to get access.

Yes. That's what I said.

The issue with it being an identifier isn't shadowing. It's that then

it's a binding with a value, and that value can be passed around,

which I suspect isn't okay.

For clarity: To get `module`, either:

1. It's a context-sensitive keyword, and code that's using it needs to

be updated when migrated to a module.

2. It's an identifier, which means its value can be passed around.

All I've said, again, is: I *suspect* that having it be an identifier

is a non-starter. But perhaps you can get support for a

context-sensitive keyword, if people feel it's worth the complexity

for mildly-improved semantics.

-- T.J. Crowder



es-discuss mailing list
mailto:es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list