Add FAQ explaining optional call semantics.

[rkirsling]

@littledan @DanielRosenwasser @bcoe @jridgewell @dustinsavery

[claudepache]

Also related: Optional chaining is not an error-suppression mechanism (last item of the FAQ). That is, its purpose is to distinguish between nullish and non-nullish, not between erroneous and correct.

Concretely, I’m planning to add the following example in the last item of the FAQ:

true?.() // TypeError: true is not a function.

(unless you decide to incorporate that change in this PR, given that you already incorporated unrelated modification of personal style choice in other FAQ items... 😛)

[DanielRosenwasser]

Optional chaining is not an error-suppression mechanism

Yup, I think that is worth specifically calling out in the FAQ in this section.

[rkirsling]

Also related: Optional chaining is not an error-suppression mechanism (last item of the FAQ). That is, its purpose is to distinguish between nullish and non-nullish, not between erroneous and correct.

Good point! I added a link from one FAQ item to the other. 👍

Concretely, I’m planning to add the following example in the last item of the FAQ:

true?.() // TypeError: true is not a function.

(unless you decide to incorporate that change in this PR, given that you already incorporated unrelated modification of personal style choice in other FAQ items... 😛)

Please do push back if there's anything you don't like... 😅 The cleanup here was intended to be mostly mechanical, after all.

Also if it's just that one line to add, you could technically incorporate it here via the GH suggestion feature! Up to you though.

[claudepache]

Please do push back if there's anything you don't like... 😅 The cleanup here was intended to be mostly mechanical, after all.

No worry, it does not make me itch when I see unnecessary </dd>/</dt>/</li>s. (Or unnecessary semicolons at the end of JS statements. BTW, I suspect that there is a strong correlation between those two style preferences?)

[ljharb]

Probably so, since neither are unnecessary - they’re so necessary the engine inserts them for you to attempt to correct your mistake ;-) but let’s not get into that debate here!

[littledan]

Thanks for this clarification and markup cleanup!

[littledan]

I might put these two paragraphs in the other order. I don't think we have to identify one of the two as the "primary" reason--they are both valid (and I would weigh the second one higher than the first, personally).

[rkirsling]

Sure, I added a commit that reverses them; hopefully folks can chime in about which they prefer.
Either way, I agree with you that neither reason need be called "primary".

[bcoe]

I might combine this and the next sentence, into something like:

furthermore, this ensures that ?. has consistent behavior with other cases like property access, i.e., if this.onChange is not callable, this.onChange() will throw a TypeError; this is consistent with the fact that optional chaining is not an error-suppression mechanism.

Take or leave my suggestion 😄

[rkirsling]

I really do want the consistency argument to stand on its own though—the fact that a?.b, a?.[b], and a?.(b) all perform the same check is an important point separate from error concerns. 😄

[bcoe]

I'm sold 👍... my only concern was that people take the decision to be driven by simplicity to implement, vs., elegance; this approach feels both the simplest to implement and most elegant to me, and I'm probably overthinking.

[claudepache]

In fact, consistency (or, said otherwise, uniformity of treatment) was my primary reason when I wrote the spec. That is, I specced it the more regular way that provides something useful for the common case (discriminating between nullish and a value supporting the following operation, be it function call or property access). Then, I checked that it did not something too weird for the edge case (something neither nullish nor supporting the following operation).

---

We can find arguments both ways. For example, when I wrote the following example in the explainer:

iterator.return?.() // manually close an iterator

i was very well aware that, although the spec did internally a similar operation when closing an iterator, it checks callability rather than non-nullity. I did not even ponder about making a note about that discrepancy, because it is an edge case.

[rkirsling]

@claudepache Would you rather that we put the two paragraphs back in their original order then (sans the word "primary")? I think that's the last remaining concern here.

[claudepache]

@rkirsling I would personally put the two paragraphs in their original order. However, it doesn’t really matter, since both reasons are valid on their own.

[littledan]

@bcoe Note that simplicity to implement has never been a factor in this discussion. All the alternatives we discussed for this proposal should be relatively simple to implement. The tradeoffs are all at the design level.

[rkirsling]

I suppose the usage-first arrangement might be considered more "developer-oriented" while consistency-first would be more targeted at people working directly with the spec (also perhaps the consistency argument is more obvious, hence our not having had a FAQ item for this previously?).

I don't know if there's a definitive answer here, but unless @jridgewell, @DanielRosenwasser, or @dustinsavery have a strong opinion, perhaps we should just move forward with what we've got.

[jridgewell]

I have no preference, let's merge.

[littledan]

Looks good to land; order is not a big deal for me.