The future of the "private" keyword

[G-Rath]

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.

[RyanCavanaugh]

Oh the other interpretation of "transformer" would be "Would TS emit private as #", the answer to which is definitely "no" because that would require type-directed emit.

[fatcerberus]

FWIW I don’t find the type-directed emit argument that strong in this case; it’s a stretch to call private “type info” IMO (also we’re emitting the class itself, so we could just say it’s an alias for # and thus not really type info at all). That said, changing TS to emit private members as # would be a massive, massive breaking change (at runtime too!), so that’s plenty good reason to avoid going that route as far as I’m concerned.

way^wayway

I found this way funnier than I should have, I think.

[fatcerberus]

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

On a related note, it’s good to know I’m not the only person who thought I had been dropped into Bizarro World when I first found out about the # sigil.

[RyanCavanaugh]

FWIW I don’t find the type-directed emit argument that strong in this case; it’s a stretch to call private “type info” IMO (also we’re emitting the class itself, so we could just say it’s an alias for # and thus not really type info at all).

Remember that private fields allow cross-instance access. Consider something like this:

class A {
  private y = 0;

  method(arg: A) {
    console.log(arg.y);
  }
}

The "correct" #-based emit of this would require type information on arg in order to detect that y should be rewritten to #y

[fatcerberus]

Yeah, I see what you mean now, basically obj.foo is ambiguous without type info if there’s a possibility it can “really mean” obj.#foo. Thanks, hadn’t thought of the cross-instance case.

[mheiber]

Other sometimes-advantages of OG private is that private fields show up in JSON.stingify output and can show up in console.log.

[gsathya]

Hi I was pointed to this thread by folks regarding the runtime performance concerns mentioned in #31670 (comment). (For some background, I implemented private fields in V8)

private fields have much better runtime perf, especially in downlevel scenarios

Can you expand on this? My understanding is that typescript private is downleved to public property access. AFAIK, the extra overhead for ES private is just one machine load for loading the PrivateName backing the property when compared to public property access. I don't expect this to be of significant runtime overhead. Is there something else?

[zhuravlikjb]

A few more questions that weren't asked yet (it seems):

1. Would #-fields allow modifiers like readonly?
2. Will public #x, private #x and protected #x be an error?
3. 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))?
4. 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. :)
   Thanks.

[nicojs]

5. Would it be possible to do this?

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

or is #baz part of the shape of Foo? (hope not so).

[RyanCavanaugh]

AFAIK, the extra overhead for ES private is just one machine load for loading the PrivateName backing the property when compared to public property access. I don't expect this to be of significant runtime overhead. Is there something else?

I over-extrapolated; I'll trust your assessment on this. I've updated the comment to be more accurate.

[RyanCavanaugh]

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 this? (structurally skip a # member)

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