Implement support for private class fields and methods

[brad4d]

See also #2731, since there are old questions and answers there about support for private fields & methods.

[brad4d]

Copied from http://go/jscbug/2731#issuecomment-3726655310 to move discussion to this issue.

From @justinfagnani

@brad4d so, what do we do if we have a library that we know is heavily relied upon inside Google and we would really like to update to using standard private fields? If we do that will Google not be able to upgrade our library until late 2026 at the earliest?

I'd say don't do it for now.

Is there some particular reason why using '#private' would be especially useful to you?

Better encapsulation, simpler tooling, and better performance.

We occasionally see accidental property clashes or intentional use of our conceptually private fields, and I would like to fix that properly once and for all. Right now we rely on a combination of naming conventions and name rewriting to protect our classes, but it's not foolproof and sometimes the conventions or renaming cause conflicts that type-checkers don't pick up because they're not aware of those build passes.

That leads into simpler tooling. We produce minified production builds even as a library because our naming conventions about what can be safely renamed are necessarily non-standard. If we want dependents to get the smallest bundle they can, we have to minify our private fields first. True private fields dodn't have this issue. Current minifiers always rename them, and it's always safe to do so. We could completely eliminate our prod builds, and the extra testing we do for them.

Then there's performance, which might be somewhat theoretical for now. Since private members are not overrideable, they're final and don't need virtual dispatch or inline caches. VMs can generate direct calls easily even in the lowest compiler tiers. For methods in hot paths, in highly polymorphic class hierarchies like UIs, this can be pretty important. It's like guaranteeing monomorphic calls with no extra work.

[brad4d]

Thanks, @justinfagnani, for your detailed response.

What you describe is similar to the benefits I would hope to get from this feature except for the performance part.

I've heard, anecdotally, that experience with private fields shows them to actually run slower in practice both when transpiled and natively. I cannot conveniently get hard data on this. If you can, I'd love to see it here.

Don't put too much effort into getting it though, since it's not likely to accelerate our implementation. There's other work our team must do that takes higher priority, and we cannot really change that, even though it does really bother me and other team members that we don't yet have support for class private fields and methods.

[brad4d]

I believe the following is a correct summary of the current state of support for this feature in closure-compiler.

1. It is recognized by the parser, but rejected as unsupported.
2. We do not yet have any implementation for transpiling it.
3. We have not yet updated any optimization passes to know how to deal with it.

@trevorade can correct me if I'm wrong here.