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 <>
> 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" <
> 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

> wrote:

Ah but you can do:

export function meta(key) {

return import.meta[key]:


On Aug 5, 2017 11:59 AM, "Dmitrii Dimandt" <
> 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

> 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
es-discuss mailing list

Reply via email to