Non-debate thread: explaining the reasons for this proposal's decisions

[mbrowne]

The goal of this thread is to begin consolidating and documenting the motivations and considerations that led to the current proposal. I think this information will be very helpful for explaining the proposal to newcomers to help mitigate negative or perplexed reactions and move them more toward, "ah, that makes sense." I think it's also useful to document the reasoning behind decisions for posterity, so that anyone interested in deeply learning the language can understand how it evolved and why. (This includes why it was chosen over alternative proposals.)

** Please pay attention to the title of this thread: I would like to avoid debates here (just in this thread). I am very much in favor of healthy debates (and have participated in plenty here) but I think for the purpose of this thread they would be noisy and distracting. **

Let me start by summarizing the general considerations regarding hard privacy. From what I can gather from @ljharb's comments, first of all hard privacy is seen as a very important requirement because there are use cases that can't be achieved any other way. Some of those use cases, such as making it impossible to branch off of the existence of a private field, or avoiding collisions with public fields, are particularly important to many library authors. It also sounds like there are members of the committee who believe that "privacy" in other OOP languages doesn't go far enough and that hard private is simply a better default—a more correct way of ensuring encapsulation.

Is that a fair summary so far of the motivation for hard private fields? I think these are good and valid arguments, but I think the case would definitely be stronger if it can be established that alternative options for hard privacy such as private symbols are unacceptable—especially given how consequential this decision is.

So I would like to pick up from my comment in #175 (comment):

It would be possible to use the private symbols proposal to cover the use cases where hard private is absolutely needed, and let private fields be soft private. I'm wondering, why did [the committee] reject this option?

It seems there is an unresolved question related to this from @Igmat:
#175 (comment)
#149 (comment)

This proxy issue with private symbols seems like a key point...after all, even @ljharb said:

private symbols, i believe, would be hard private, not soft, and if so that’d be fine with me - but I’m told they have issues with membranes, and as such are not an option.

OTOH, it's moot if the committee's position is that soft private is simply a bad default even if there are other ways hard privacy could be achieved. I'm not clear on the committee's reasoning on this.

[mbrowne]

I forgot to mention...for those who haven't checked the readme for this repo in a while, more details on committee decisions can be found in the links provided under "Development History":
https://github.com/tc39/proposal-class-fields#development-history

So this thread is for clarifying and asking follow-up questions, not for revisiting the whole decision process from the beginning.

[littledan]

The argument against private symbols eventually became, once you have all the "right" semantics, it is so far away from ordinary properties that it's not reasonable to make them treated as property keys with [] anymore. That's why decorators makes PrivateName not a Symbol/property key, even though it serves the same role.

[littledan]

Apologies for my delay here and thanks for following up like this!

[Igmat]

once you have all the "right" semantics

@littledan what are the "right" semantics?

[littledan]

@Igmat, @erights has repeatedly stated that the semantics must be analogous to WeakMap, so that's what I was getting at with "right". I see this as a little more of a tradeoff than an absolute (but, in the end, a decent tradeoff), which is why I used quotes :)

[mbrowne]

Thanks @littledan. Can you comment on the committee's overall views regarding alternative solutions for hard private? For example, if private symbols didn't have these issues and were seen as a fully workable proposal, would the committee have been likely to consider making private fields soft private instead of hard private? Or would it have maintained its preference for hard private class fields? I'm asking these hypothetical questions as a means to an end: I'm trying to get at the driving forces behind the total rejection of private x syntax. I'm piecing it together, but with so many different arguments that have been presented, it's hard to tell from the outside what really sealed the deal and how the wishes of various stakeholders (e.g. library authors, users interested in reflection features, etc.) were balanced.

FWIW I see both pros and cons of fields being hard private by default, and even without knowing all the details the committee's decision on this seems very reasonable to me. So I'm not asking for a primer on the benefits of strong encapsulation by default, but rather clarity about which of my points in the OP were most salient to the committee and whether I missed anything that was a significant factor in the decision.

[bakkot]

For example, if private symbols didn't have these issues and were seen as a fully workable proposal, would the committee have been likely to consider making private fields soft private instead of hard private?

I don't think so. You can read some of the discussion here, if you like, but my position and, as I understand it, the position of several other members of the committee is that "soft" private is not meaningfully distinct from symbols as they currently stand, so if we're adding a new thing for private state, it should actually provide privacy.

As to which should be the default, it is my position that it should be the case that the default behavior for a new feature is the new capability it provides, not the thing you could do already.

(That said, private symbols would be "hard" private, as I use the term, unless they triggered proxy traps.)

I'm trying to get at the driving forces behind the total rejection of private x syntax

The FAQ already summarizes my position on this to the best of my ability. The short version:

• It is unacceptable for adding private state to an object to prevent other code from adding any public property to that object (or its own private state, no matter the name).
• It is unacceptable to introduce static types as a prerequisite for this feature.
• It is unacceptable for a single occurrence of this.x to mean different things at runtime depending on the value that this happens to have at the time.
• It is unacceptable for introducing or renaming a private field to change the behavior of code elsewhere in the class which is not intending to operate on instances of the class.
• As a consequence of the previous four points, having access be this.x is not workable.
• It is unacceptable to have field declarations of the form private x without having this.x access that field.
• As a consequence of the previous two points, private x is not workable.

None of these points really depend on the hard vs soft thing.

Of course, other committee members may have their own opinions. This is an inevitable part of the consensus process - even if everyone agrees on a design, they won't necessarily (or typically) agree on the reasons for it. So I'm afraid you're unlikely to get a statement from the committee as a whole on this.

(Edit: forgot one more point: It is unacceptable for the this keyword to get any new special semantics.)

[littledan]

My understanding of the committee's position matches @bakkot's, even if my personal feeling is that many of these things are tradeoffs rather than unacceptable.

[panlina]

This is a good suggestion. Can anyone pick up to summarize considerations behind [[Define]] semantics for public fields?

[mbrowne]

Thanks @panlina...I was intending to follow up on this thread, just hadn't gotten to it yet.

First of all, thanks very much to @bakkot and @littledan for the explanations. I think we have the beginnings of a rationale document here. I think there is also another point in favor of hard privacy in addition to what you mentioned, which is that soft privacy (without making fields fully public) is still easily available via decorators. Although...it's not actually quite as easy as I originally thought it would be, since only field-level decorators (and not class-level decorators) have access to private fields in the latest decorators spec, but that's a discussion for the decorators repo.

[mbrowne]

Regarding [[Define]] vs. [[Set]], I agree that's a very good choice for a next topic to discuss here. I still don't really understand the case for Define and strongly favor Set (for practical reasons), but I'll take a stab at summarizing the argument to get the process started...

As best I can tell, the main argument in favor of Define is avoiding side effects, meaning that declaring a public field should always do one and only one thing: define an own property of the instance. It seems that the distinction between declarative and imperative syntax is important here; field declarations are intended as declarative syntax, so side effects such as a getter or setter being called (which would be acceptable in an imperative setting) are undesirable. What I don't think has been demonstrated is that there are significant practical downsides to Set, or at least none that come close to the significance of the practical downsides of Define, i.e. potentially confusing issues for developers and resulting bugs. (Purely declarative semantics do have the practical benefit of helping to make code more readable and predictable in general ways, but I'm referring more to specific points of confusion or surprising behavior specific to Javascript and its established expectations.) I bring this up here because although this is a non-debate thread, I would definitely appreciate any committee members describing more practical issues with Set that I might have missed.

One other issue with Set I've seen mentioned by committee members is that it could complicate the implementation of decorators. @ljharb offered an alternative interpretation, saying that Define also comes with its own challenges for implementing decorators, and it's more of a 6 in one half dozen in the other situation. @littledan, perhaps you could weigh in here as one of the champions of the decorators proposal (and also this proposal of course)?

[mbrowne]

I followed up on my point about reflection here:
tc39/proposal-decorators#191

[littledan]

#196 takes a first stab here. I merged it already, but review comments still welcome.