Emit actually-private members for classes, for runtime.

[trusktr]

Suggestion

I already read the FAQ regarding this, but private members are possible, and it'd be nice to (optionally) have them at runtime.

Use Cases

So people interacting with your code at runtime experience the restrictions we desired them to have. They might not use TypeScript.

Examples

See lowclass (look at the extensive tests files showing all sorts of uses of runtime public/protected/private members). The implementation is not long, and some features can be omitted in order just to have the minimal protected/private functionality.

It uses WeakMaps to store protected/private state.

Babel also has private member feature.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • It will break JavaScript code that is improperly relying on emitted internals that should be private.
• This wouldn't change the runtime behavior of existing JavaScript code
  • Same as previous.
• This could be implemented without emitting different JS based on the types of the expressions
  • emits different runtime code
• This isn't a runtime feature (e.g. new expression-level syntax)
  • it is basically a runtime feature, doesn't change anything related to types.

[weswigham]

You should be monitoring #9950 for implementation of the official ECMAScript runtime privacy proposal.

[trusktr]

Oh sweeet, and sorry. Closing this one.