The future of the "private" keyword

This is a somewhat “catch-all” issue to serve as a place of discussion for a question that is sure to come up given the advancement of Private-Named Instance Fields:

---

What is the future of the “private” keyword in TypeScript?

That’s the general question - following are some short-and-sweet Q&As that I’ve pulled up for visibility.

Is TypeScript going to depreciate it, and aim towards phasing it out in favor of the private field operator?

Our current plan is to leave the current private behavior as-is.

Is it going to be supported in the form of a transformer , turning private bar into #bar?

definitely “no” because that would require type-directed emit.

A few more questions:

Would #-fields allow modifiers like readonly?

Yes, readonly is meaningful inside the class

Will public #x, private #x and protected #x be an error?

Yes

Will it be possible to assign #-fields from the constructor parameters, the same way as the current parameter-properties work (i.e., constructor (private x) and constructor (#x))?

No

What visibility rules will apply between private entities and #-entities? What if I use a private-entity from a #-entity, or vice versa? Seems that #-entites are ‘more’ private than private-entities, in some sense. 😃

The visibility of a method doesn’t change which properties it’s allowed to access

Would it be possible to do the following:

class Foo {
    bar: string;
    #baz: number;
}
const foo: Foo = { bar: 'bar' };

No. The given object is not a substitute for Foo; the same reasoning about cross-member access requiring private members to be present applies here

[AnyhowStep]

I would personally prefer to keep the private keyword. To me, it looks way^wayway better than #. And is more clear in its intent, to me. And I wouldn’t want to have to go back and do a regex replace for private to #.

When I found out # was being proposed instead of just private, I thought I was experiencing the Mandela effect.

[RyanCavanaugh]

Our current plan is to leave the current private behavior as-is.

Reasons for this:

• We don’t make breaking changes for no reason, and nothing external is forcing people to move off of compile-time private
• There are very good use cases for compile-time-only privacy:
  • private fields can be read from unit tests (I realize some people find this personally distasteful, but this is not universal)
  • private fields have much better runtime perf in downlevel scenarios
• Lots of people don’t like the # syntax so why force it on them
• Without WeakMap (which not all runtimes have) there’s no good equivalent downleveling for hard runtime privacy

As for a transformer, probably not? It’s simple to replace these with a regex if you’re motivated.