Add support for ES.Next private methods and private accessor properties

[PetaSoft]

Search Terms

TypeScript 3.9, TC39, Stage 3, ES.Next, private methods, private accessor properties, #methods

Suggestion

Private methods and private accessor properties (both static and instance) are currently at stage 3 of the TC39 working group. They will hopefully be part of the ES2021 standard. The Google Javascript V8 engine in Version 8.3 and Node.js 13.2+ support these features already if one uses the flag --harmony-private-methods. Google Chrome 84, and Google Javascript V8 8.4 engine will support them officially (see compatibility table). Node.js will probably follow soon after the Google Chome 84 release.

Use Cases

TC39 private methods and private accessor properties offer standard compatibility with future Javascript versions.

Examples

class newFeatures {
  static #classMethod(): void {   }
  static get #classPropertyAccessor(): number { return 0; }
  static set #classPropertyAccessor(v: number): void {   }
  #instanceMethod(): void {   }
  get #instancePropertyAccessor(): number { return 0; }
  set #instancePropertyAccessor(v: number): void {   }
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[Thor-x86]

FYI, we can actually bring private accessor to browser with ES5. Here's the example:

TypeScript

class LoremIpsum {
    public name:string = "kucing";
    public myPublic:string = "I have paws";
    private myPrivate:string = "My password is: L0rd-Bruh";
    
    constructor() {
        this.privateLog(this.myPrivate);
    }
    
    public publicLog(input) {
        console.log(`[publicly from ${this.name}] ${input}`);
    }
    private privateLog(input) {
        console.log(`[privately from ${this.name}] ${input}`);
    }
}

ES.Next:

const LoremIpsum = (function() {
    function privateLog(input) {
        console.log(`[privately from ${this.name}] ${input}`);
    }
    
    return class LoremIpsum {
        #myPrivate; // Every private properties must be declared here
        constructor() {
            this.name = "kucing";
            this.myPublic = "I have paws";
            this.#myPrivate = "My password is: L0rd-Bruh";
            
            // Transpiled constructor from TS:
            privateLog.apply(this, [this.#myPrivate]);
        }
        publicLog(input) {
            console.log(`[publicly from ${this.name}] ${input}`);
        }
    }
})()

ES5:

const LoremIpsum = (function() {
    const _priv_myPrivate = new WeakMap();
    
    function privateLog(input) {
        console.log("[privately from " + this.name + "] " + input);
    }
   
    return class LoremIpsum {
        constructor() {
            this.name = "kucing";
            this.myPublic = "I have paws";
            _priv_myPrivate.set(this, "My password is: L0rd-Bruh") ;
            
            // Transpiled constructor from TS:
            privateLog.apply(this, [ _priv_myPrivate.get(this)]);
        }
        publicLog(input) {
            console.log("[publicly from " + this.name + "] " + input);
        }
    }
})()

Conclusion

Bring accessor to browser side is possible, especially for TypeScript. Someone did submitted the proposal to Babel and confirmed working at version 7.2.0. So, it's TypeScript's turn :)

Cheers!

Reference: Stack Overflow - Private properties in JavaScript ES6 classes

EDIT: Fixed code for ES.Next

[KilianKilmister]

@Thor-x86

FYI, we can actually bring private accessor to browser with ES5. Here's the example:

You actually can't (in V8, with the shown code). private fields need to be declared in the constructor first or you'll get this error: Private field '#myPrivate' must be declared in an enclosing class

class LoremIpsum {
        constructor() {
            this.name = "kucing";
            this.myPublic = "I have paws";
            this.#myPrivate = "My password is: L0rd-Bruh";
         }
 }

ts-v4.0.2
V8-v8.5.210.20

Playground Link

NOTE

i just checked up on it, as i've been using them for ages. didn't know that Spidermonkey still doesn't support them. Chome had support for them in stable release since april 2019

[Thor-x86]

As correction, the part of code that you tested on TS playground supposed to be executed with EcmaScript Next instead of Typescript.

[KilianKilmister]

@Thor-x86 yeah, i ran it untranspiled, was just the easiest way to include a link

looks the same in my terminal:
node-v14.8.0
V8-v8.4.371.19-node.12

            this.#myPrivate = "My password is: L0rd-Bruh";
                ^

Uncaught SyntaxError: Private field '#myPrivate' must be declared in an enclosing class
> 

same code, same engine, same result

[Thor-x86]

@Thor-x86 yeah, i ran it untranspiled, was just the easiest way to include a link

looks the same in my terminal

Thanks @KilianKilmister for reporting the mistake. I just realized that I forgot to declare #myPrivate; like on the fixed code above. I have no idea why we need to declare it in "Java Style" for private properties.

[KilianKilmister]

@Thor-x86 it's was decided to be part of the standard (see: link)

---

General Update: The latest releases of node now ships with private variants for all classfields. both instance and static enabled by default.

I believe it's about time this feature request gets a triage, as this has very much moved past the discussion stage.
The code in the example should transpile to this when target: 'esnext is set, as it is now valid JS/ES code.

class newFeatures {
  static #classMethod() {   }
  static get #classPropertyAccessor() { return 0 }
  static set #classPropertyAccessor(v) {   }
  #instanceMethod(): void {   }
  get #instancePropertyAccessor() { return 0 }
  set #instancePropertyAccessor(v) {   }
}

Typescript already mocks all of these anyways, and it would be great to be able to use them without a compiler error.

At this point error number TS18022 and TS18019 are borderline bugs in a node-v14.10 environment

error TS18019: 'static' modifier cannot be used with a private identifier
error TS18022: A method cannot be named with a private identifier.

---

If you are using chrome and it's reasonably up to date you can try the following in some JS playground.

NOTE: the typescript playground doesn't output console.log very well, but you can use playcode.io for example.

class Test {
  static #secret = 42 // static private field
  static #changeSecret () { // static private method
    Test.#secret = 12
  }
  static get #abc () {return 'xyz'} // static private accessor

  constructor () {
    console.log(Test.#abc)
    this.#method()
  }

  #method () { // private instance method
    console.log(Test.#secret)
  }

  accessor () { return this.#tryToGetMe }

  get #tryToGetMe () {return 'You did it!'} // static private accessor

  static tellSecret () {
    const secret = Test.#secret
    Test.#changeSecret()
    return secret
  }
}


console.log(new Test().accessor())
console.log(Test.tellSecret())
console.log(Test.tellSecret())

console output:

xyz
42
You did it!
42
12

[dragomirtitian]

@DanielRosenwasser @RyanCavanaugh

Me and @mkubilayk are now implementing private methods and accessors, with the hope of having it ready in the 4.3 time frame.

We'll share the code early as we build it on the Bloomberg public repo.

This change will impact all parts of the compiler.

The basic steps to implement are:

1. Parsing - This appears to be mostly there due to work on private fields, but we need to remove the semantic error this is not supported.
2. Add support in the binder for private methods and accessors when building class member symbol tables.
3. Type checking private methods will use the same infrastructure as regular methods, we just need to ensure that private methods are part of the class type member list
4. Emit support - This is not currently present at all will need to be added
5. Declaration emit support - Probably no additional support needed beyond ensuring #private is emitted for methods and accessors as well.
6. Code completion - Ensure these work as expected, by adding tests.