Compatibility with ECMAScript Private Fields proposal

[dennis-johnson-dev]

Being that TypeScript already has features such as private class fields and the syntax is different from the proposal, I was curious how new ECMAScript proposals would be either integrated/supported into new versions of TypeScript or whether the plan was to only support the existing syntax for private fields.

I know it's one of TypeScript's goals to align with current and future standards, but it puts usage in a bit of a weird spot. Do users use both forms of syntax, only what is standard, or only what TypeScript has already implemented?

Any thoughts on how to approach using new ECMA features and/or integrate with existing TypeScript code would be greatly appreciated.

Thanks!

[DanielRosenwasser]

I think the two features can coexist together. One is design-time privacy which I think by and large has been useful for TypeScript users. It's a "soft" privacy check and this approach has its merits like debugging, and allowing consumers to use your code until you've figured out how you want to surface your API. The emit for our accessibility is entirely erased, which leads to simpler emit, while adding explicit intent to consumers; and intent goes a very long way in programming.

The other is runtime privacy. This mode of privacy currently can't be used on methods on the prototype, or on static fields (and I don't know if there is any concrete proposal that does so). In other words, the following doesn't work

classs C {
  // doesn't work
  #foo() {
    // ...
  }

  // doesn't work
  static #bar = 10;
}

You can think of TypeScript's design-time privacy checks as compatible with both instance field placement proposals, where run-time private fields can only be design-time private:

TypeScript modifier...	with public fields	with private fields
No modifier	Entirely public	Private at run-time & design-time
public	Entirely public	Incompatible
protected	Design-time protected	Incompatible
private	Design-time private	Private at run-time & design-time

In general, it's a set of tradeoffs for you to choose from. I think I and the majority of our team feel that design-time privacy is good enough on the whole. If private fields proceed, then you'll be able to choose something that enforces runtime checks as well if it's what you need, but keep the tradeoffs in mind.

[dennis-johnson-dev]

Thank you so much for the thoughtful reply! There's a lot of great insight here in using what suits our needs best and understanding the tradeoffs. I'll go ahead and close this issue.