Broad inclusion of operators

[littledan]

This proposal includes not just ?. but also ?.[ and ?.(. It's easy to see why ?. is useful when navigating around a JSON document, and ?.[ may be for analogous situations, but the method call and constructor parts are a bit more obscure. Are these included out of an abstract sense of orthogonality, or were there particular use cases in mind that motivated them? If so, it would be good to include them in the explainer. IIRC the number of operators here was brought up at the January 2017 TC39 meeting as a point to revisit with an eye towards starting more minimally. cc @dherman

[claudepache]

Below are some food for thought. I may find more use cases.

(1) Given an iterator iter, you could close it manually with:

iter.return?.()

(2) Given a DOM element foo, you could run manually its eventual DOM0-onclick handler with:

foo.onclick?.()

(3) More concretely, I’ve recently encountered a situation where I wanted to run the reportValidity method of an HTML form, but fall back to skip the check for browsers which don’t implement that method (since there is of course another check server-side):

if (myForm.checkValidity && !myForm.checkValidity()) {
    // validity check has failed and errors are reported to the user
    // stop processing the form
    return;
}

With ?.(, I could have written:

if (myForm.checkValidity?.() === false) {
    // validity check has failed and errors are reported to the user
    // stop processing the form
    return;
}

because myForm.checkValidity?.() will evaluate to true or false for browsers that implement it, and undefined for those that don’t implement it yet.

[littledan]

Those all make sense to me. Did you have anything in mind for the constructor case?

[claudepache]

For the constructor case, no, I’ve currently nothing in mind except completeness.

[claudepache]

If we want to be super complete, besides the “optional constructor” case new a?.(x), there is also the obscure “optional tagged template” case a?.`{x}`. For those two forms, in absence of compelling use cases, I don’t care.

[littledan]

Seems like there are two decisions: which forms to include for .? versions, and which forms to short circuit over, even in the ordinary version. Would it make sense to choose the same set of forms for both of these?

[claudepache]

Seems like there are two decisions: which forms to include for .? versions, and which forms to short circuit over, even in the ordinary version. Would it make sense to choose the same set of forms for both of these?

For me, it would make sense that the first set is included in the second set.

[littledan]

@claudepache Yes, I agree about the subset relationship; I'm suggesting that maybe they should be equal (regardless of how expansive or restrictive we make things). The idea would be that it's less to learn.

For reference, these sets are not equal in C#--the only forms are ?. and ?[, but then short-circuiting happens over ?( as well. However, there is the subset relationship that Claude mentioned above.

[claudepache]

@littledan No, I don’t think that making the two sets equal make it less to learn, because it is not a useful rule. For instance, does it say whether super?.foo is allowed? (BTW, it is not. Still an obscure case that I didn’t try to spec.) Personally, I can’t even answer.

[littledan]

OK, this seems reasonable. super?.foo does seem pretty obscure and useless, for one. Should we leave out new and templates, if utility is a thing we're thinking about here, and we haven't thought of use cases for them yet?

[claudepache]

I think that new (and templates) should be dropped in absence of use case. (In CoffeeScript, “soaked new” is implemented but unused in practice per #17.)

[claudepache]

@claudepache

No, I don’t think that making the two sets equal make it less to learn, because it is not a useful rule. For instance, does it say whether super?.foo is allowed? (BTW, it is not. Still an obscure case that I didn’t try to spec.) Personally, I can’t even answer.

I disagree with my past self. For someone not versed in the spec details, it would seem like an arbitrary restriction or an inconsistency if some construct is allowed in some location of an optional chain, but not in another. The case of super is a red herring, because it is a special feature for which it does not make much sense to be considered as ”optional”.