How to fix the `class` keyword

Brendan Eich brendan at
Thu Mar 5 06:43:55 UTC 2015

Leon Arnott wrote:
> Well, they're a distinct special form that can be used in expression 
> position, and evaluates to a function, so they're definitely, to bring 
> back an old coin, quasi-literal. (I personally think your reasoning 
> entails that arrows aren't function literals because of their lexical 
> `this` bindings.)

(That doesn't follow, but let's not quibble -- in any case, "literal" is 
the wrong word.)

The bigger problem is that we do not want class syntax for declaring 
properties on the prototype, which is what

   class C {
     d: 42,

would denote if you really mean object initialiser expressing the 
prototype object as class body.

> So, stuff inside class bodies should be considered more like function 
> statements, not property definitions - even though they have a lot of 
> *very* property-ish things, like computed names, or shorthand methods, 
> or accessors, or shorthand generators... :|

It's neither fish nor fowl.

Special forms are special, they mean what we say. Of course we should 
use good taste and clear precedent where we can. I'm saying object 
initialisers are not good precedent, and false taste (like fake sugar -- 

> And, according to that gist, data properties should be considered to 
> be like assignment statements. Would that make a hypothetical `class { 
> [foo, bar] = [1,2]; }` a destructuring or a computed property name? 
> Either answer seems dissatisfying (the former because it precludes the 
> latter; the latter because it mis-resembles the former).

The proposal from Jeff is just a straw item for ES7, but it seems better 
than using data property syntax (see above). It'd still be a special 
form, so restricting the LHS to exclude destructuring patterns is not 
hard on either grammar or users.


More information about the es-discuss mailing list