[JavaScript] Missing ES7 features

[ccampbell]

I don’t know if you would prefer these to be in separate tickets, but here are a couple things missing in the native JS syntax (that I am aware of).

• Async methods inside of a class

  class SomeClass {
      async instanceMethod() {
      }
  
      static async someStaticMethod() {
      }
  }

• Class static and instance properties (taken from Babel site)

  class Bork {
      //Property initializer syntax
      instanceProperty = 'bork';
      boundFunction = () => {
          return this.instanceProperty;
      }
  
      //Static class properties
      static staticProperty = 'babelIsCool';
      static staticFunction = function() {
          return Bork.staticProperty;
      }
  }

I am not sure what scopes they should be. The async keyword highlights as entity.name.function right now. The static and instance properties currently cause the highlighting to break:

[aziz]

Please also read the comments from @bathos on bathos/Ecmascript-Sublime#33

[FichteFoll]

FYI, async is storage.modifier.async.python in Python.

[bathos]

@aziz Didn’t catch earlier that you were referencing something here. As mentioned in the other thread, the first example here contains a syntax error (async static should be static async) and I’m unsure if that impacts how the base JS grammar handles it, while the latter may or may not (the missing semicolon after the second assignment may not be handled by ASI; this is an unknown still). Two things that might be useful to folks here:

• async functions are an es2017 (whereas es7 is an informal name for es2016) feature. Although the current version of ES is ES2016, ES2017 has a fixed feature set and syntax now and has been implemented in most browsers, so it is safe to consider this part of the language.

• instance properties are not part of any version of ES currently. It is a proposed feature and the syntax, semantics and ultimate fate of the feature are not a sure thing yet. I don’t know what the goals for the base JS def in sublime are, but if there is not yet a policy for inclusion you may want to add one, since supporting a stage 1 proposal implies supporting a lot of other tentative new things which may or may not actually become part of Javascript.

For more info on the potential syntax needs related to in-flight class extension proposals see:

• https://tc39.github.io/proposal-class-public-fields/
• https://github.com/tc39/proposal-private-fields
• http://tc39.github.io/proposal-decorators/

and most importantly,

• https://github.com/erights/Orthogonal-Classes

[ccampbell]

Sorry bout the syntax error! Just updated it