"Short-circuiting" feature

[littledan]

In this proposal, as the explainer says,

a?.b.c().d   // undefined if a is null/undefined

The "short-circuiting" semantics received some criticism at the previous TC39 meeting where the proposal was discussed. A few committee members (including Waldemar Horwat) expressed a preference that this would throw (on the access to .c) to keep the semantics simple and more locally understandable, and refrain from changing .. The explainer talks about the "right hand side", but where does the right hand side end exactly?

If you don't plan to remove this feature, it would be useful to extend the explainer with some more motivating use cases.

[xtuc]

This is related to #2. The question is when does the Nil reference ends its propagation.

[littledan]

@xtuc Yes, it's related; I had missed that bug. I meant this bug to track a more basic question: do we need Nil at all, or can we just say that ?. always outputs an ordinary JavaScript value? But you can think of this as "Nil never propagating at all".

[claudepache]

to keep the semantics simple and more locally understandable, and refrain from changing ..

I’ve planned to give an alternative informal description of my envisioned semantics in terms of abrupt completions instead of Nil reference; I’ve not done it yet due to some IRL concerns, but I promise to do it the next few days. I hope that that alternative description will convince that there is more locality than what is apparent at first glance.

The explainer talks about the "right hand side", but where does the right hand side end exactly?

In that context, the “right-hand side” means basically “everything that is on the right of ? inside a chain of property accesses, method invocations, etc.”, where “property accesses, method invocations, etc. ” is approximately what is found in Section LeftHandSide Expression of the spec. That is not an exact characterisation, by I hope it gives an idea in simple cases.

[littledan]

@claudepache Sorry, I guess I meant that "where does the right hand side end exactly" question a bit more rhetorically--you definitely defined things clearly, but from a user perspective, is . so different from other operators? I don't see why it should be.

[xtuc]

Can you look at the comments in #2, there are example of that.

[claudepache]

but from a user perspective, is . so different from other operators?

The short answer: the precise place where the short-circuit ends is where it is the most useful for the user, while remaining relatively simple to understand. It is a balance between usefulness and simplicity.

For the long answer... I expect to write it soon in my repo (also, after I’ll have read #2).

[xixixao]

Note that you can get the "other" desired semantics by doing (a?.b).c().d, but if you make that the default semantics, you will force users to do a?.b?.c?.()?.d. So the two options for expressing these two different expressions are:

// proposed
x = a?.b.c().d
y = (a?.b).c().d

// vs
x = a?.b?.c?.()?.d
y = a?.b.c().d

where y is something that you almost never want to do, and x is what you almost always want. On this alone you would choose the proposed semantics, but there is even more important consideration:

What if a.b is null.

if I want x to throw when a.b is null, I can no longer express x in the "other" semantics. I would have to do:

// proposed
x = a?.b.c().d

// vs
x = a == null ? null : a.b.c().d

which, clearly, is not using the operator at all, completely defeating it's purpose. This is why the current proposal is more "local", as it incentivize users to put ?. only after the one nullable object in a chain.

[rattrayalex]

While @xixixao 's case should be sufficient to show that "short-circuiting" is the only usable form of this feature, here is another argument in its favor:

given

type User = {
  id: string,
  // ...
  address: {
    street: string,
    // ...
  }
}
function getUserIfExists(id): ?User {
  if (users[id]) return users[id];
  return null;
};
const user = getUserIfExists('user_abc123');

// as proposed:
const street = user?.address.street; 
// without "short-circuiting":
const street = user?.address?.street; 

The latter version doesn't make much sense; a user should always have an address. Given a user, we would want to throw if its address == null.

However, without short-circuiting, we would be forced to write user?.address?.street because of the (valid) possibility of user == null.

Thus, the genuinely incorrect case of user = {} would not throw, even though we would want it to.

[ljharb]

Short-circuiting on member access is fine, and obviously the proposal is almost useless without that.

I'm suggesting that extending that short-circuiting to function invocation is problematic.

[rattrayalex]

Ah, perhaps I misunderstood what exactly is meant by "short-circuiting" (judging by discussions in the babel slack channel #proposal-opt-chaining).

eg; one committee member seems to desire:

• given a?.b.c and a == null, no error
• given a?.b.c() and a == null, throw error

...which seems like very surprising behavior to me.

EDITED EDIT:

I believe @ljharb was responding as if we were on another thread (#2) as it's a bit unclear what the distinction between them are. It's my impression that @ljharb is in accord with @xixixao , @jridgewell, myself, and others on this particular thread, but in disagreement on the question of #2.

Apologies for the confusion 😄

[jridgewell]

@rattrayalex: That particular issue is being discussed in #2. This one is concerned with:

a?.b.c;     // a = {b: { c: 42 } }
a?.b.c;     // a = null

From OP:

A few committee members (including Waldemar Horwat) expressed a preference that this would throw (on the access to .c)

Specifically, the second case should throw (you have to use ?. all the way down). I hate this.

[ljharb]

@jridgewell to clarify, in both cases, a = {} would throw on .c, yes?

[rattrayalex]

@jridgewell @ljharb does everyone on TC39 agree with:

Short-circuiting on member access is fine, and obviously the proposal is almost useless without that.

If so can this issue be closed?

Pardon my confusion 😄

[jridgewell]

Lol, I guess there are 3 cases:

a?.b.c;     // a = {b: {} }
a?.b.c;     // a = {}
a?.b.c;     // a = null

OP would have us throw in case 2 and 3. I argue that only case 2 should throw (because b.c isn't using optional chaining).