Expected interop with private field access?

[loganfsmyth]

What is the expected interop with private-field property access? https://tc39.github.io/proposal-class-fields/#sec-updated-syntax

Should

foo?.#prop

be considered valid syntax?

[ljharb]

I would hope that it would still throw if the slot wasn't present, and only reacted to null/undefined

[loganfsmyth]

Could you clarify what you mean by only reacted to null/undefined? My assumption was essentially that it'd be an identical transformation as the normal property access, e.g.

var val = base?.#prop;
// to
var val = base == null ? void 0 : base.#prop;

I think that is what you're describing too?

[ljharb]

ah, while that's not what I meant, i guess that'd make more sense.

[claudepache]

Yes, class fields as well as private methods will naturally be considered with the obvious semantics. I expect to add a note in the explainer (but it is premature to add that in the spec text proper at this point).

[claudepache]

@ljharb

I would hope that it would still throw if the slot wasn't present, and only reacted to null/undefined

A possible misconception (or misleading mental model) is to consider ?. as if it was some sort of error-silenting operator. By design, the operator does a tight and well defined test (quite the opposite of an error-silenting operator) on its LHS, and does not change the semantics of its RHS (whether it throws or not).

[littledan]

This has been asked a number of times before. I think the syntax of x?.#y composes pretty naturally. However, it's hard for me to think of a use case. Just as this proposal currently omits new C.?(), I think it's reasonable to start with leaving out x?.#y even if private fields are already at Stage 4 by the time this gets to Stage 2-3.

I agree with others in this thread that I'd prefer the semantics of x?.#y to just affect operation on null/undefined, and not suppress other, unrelated TypeErrors.

[claudepache]

I’ve not thought of a concrete use case, but the way I would try to construct one is the following. Think of a situation where you expect either an object of specific shape (in our specific case, an instance of the current class), or null/undefined. Then, think of an action to trigger with that object (get a value, call a method, etc.), that you want to skip when you have null/undefined.

More generally, that situation of “either an object of known shape or null” is (I think) a major source of use cases for optional chaining, be it optional property access, optional method call, optional function call, and even optional property deletion or optional property assignment (#18).

I agree with others in this thread that I'd prefer the semantics of x?.#y to just affect operation on null/undefined, and not suppress other, unrelated TypeErrors.

Again, optional chaining has never been intended to “suppress errors”. (At least in my mind.)

[Mouvedia]

Again, optional chaining has never been intended to “suppress errors”.

It could also have been interpreted as choose where I let it throw granularly.

[claudepache]

It is difficult to find use cases, because it is unusual to use private fields/methods with anything else than this, to begin with. What are the custom uses cases of private stuff with non-this base?

[ljharb]

@claudepache i don't find it particularly unusual:

static isEqual(a, b) {
  return a.#id === b.#id; // or something 
}

also:

constructor(stringOrInstance) {
  if (typeof stringOrInstance === 'string') {
    this.#id = string;
  } else {
    this.#id = stringOrInstance.#id; // construct via copy
  }
}

[littledan]

Not sure why discussion is starting again now, but I am wondering if we'd be OK omitting this operation for now for the reasons I explained in #28 (comment) .

[ljharb]

I think it doesn't add much value to allow it now - but I also think it makes the language a bit more consistent. a?.#b still wouldn't suppress the error if a lacked the private field for #b - but it would allow pivoting on whether it was undefined or null.

Specifically, I'd envision a use case of an initializer of #id;, and then using .? in other code in the same class to short-circuit unless the #id had previously been set (while still throwing on an invalid receiver)

[littledan]

I'd like to just be content with the understanding that the syntax composes well, and leave this for consideration to add in the future. This proposal is specifically not trying to add all combinations, but start with the three most useful ones.

[adrianheine]

Private element accesses can still occur as part of an optional chain, though, right?

class X {
  #c;
  c() {
     return this.a?.b.#c // return this.a != null && this.a.b.#c
  }
}