Support for `?. PrivateIdentifier`

[jridgewell]

Continuing discussion from https://github.com/tc39/proposal-class-fields/pull/301#issuecomment-597264285

(Not related to timing of the PR, we can do either a followup on this proposal or a needs-consensus patch on ecma262. Either is fine with me.)

I see foo?.#baz support as being just another form of foo?.bar.#baz. I think developers will end up being confused why they can do one syntax but not the other. Private field access feels like it is just part of the chain, no matter where that chain starts.

[tabatkins]

Agree. I still find it kinda weird that ? automatically chains to further accesses, but given that it does, having foo?.bar.#baz work but foo?.#baz be an error seems extremely inconsistent and confusing. Regardless of what semantics one might attach to the particulars of private-field access, removing a link from a chain shouldn't create a syntax error.

[ljharb]

I agree. Addressing this seems like the responsibility of whichever proposal landed second; since that’s this one, it seems like this proposal should adapt to include this case.

[littledan]

I'd prefer to omit this support. I think considering it is the responsibility of the second proposal (i.e., this one), but I don't think the conclusion either way is determined.

[bakkot]

@littledan can you say why? It seems like a very natural thing to include, to me.

[ljharb]

Same to me. One common use case I have for private fields is static methods that take in possible instances to brand check; being able to use optional chaining on them (obj?.#foo) means I don't have to special-case nullish user-provided values.

[tabatkins]

And just for consistency, if obj?.#foo is a syntax error, but {obj}?.obj.#foo works and does the desired thing, we done goofed.

[rdking]

My 2¢. If ?. has landed, and it guarantees that for every x.y, x?.y is also valid, then it is an inconsistency if when y is substituted by #y an error is generated. Breaking like this implies that .# is an operator. That goes directly against the model you're trying to push.

[littledan]

So, let me start by saying that my opposition here is weakly held. I'll explain here why my intuition is to exclude this feature, but I am happy to defer the result of the committee discussion.

First, let's remember that the optional chaining proposal is deliberately minimal. ?. does not compose with everything. We decided this a long time ago, in issues like https://github.com/tc39/proposal-optional-chaining/issues/18 . This decision was informed by concrete data, such as usage in CoffeeScript (https://github.com/tc39/proposal-optional-chaining/issues/17), in addition to analyzing specific scenarios where it was unclear what semantics exactly to give.

Here, I think we have both issues:

• There have been multiple semantics proposed: undefined for missing private field vs undefined for null/undefined receiver. However, we could simply answer the latter, which I think everyone here is arguing for. Also, the fact that someone proposed something else isn't really fatal--we also heard suggestions that f?.() should check IsCallable, but settled on null/undefined.
• It didn't feel to me like it logically made sense the way that the others do. I felt like optional chaining was more for "data-like things", like JSON or things created for object literals, and less for class instances. However, this is just my personal intuition, not part of the optional chaining explainer, and this thread seems to show that many people didn't share my intuition.

All in all, when I write it out, those aren't such strong arguments. For this reason, I'm happy to go with the committee on this one.

[jridgewell]

This was resolved in committee, and support was landed via https://github.com/tc39/proposal-class-fields/pull/301.