Unary operator ??

[saschanaz]

The binary operator ?. means optional chaining, but here the unary operator ?? means it gets an "optional-chaining" state that the following syntactic access to the "optional" object doesn't throw even if the object is null/undefined.

??x.y // x safely can be null/undefined,
??x[y]
??x(y)
??x // same as x, no effect

a.??b.c // a.b safely can be null/undefined
a.??b // same as a.b, no effect
(a.??b).c // will throw if a.b is null/undefined

??(foo(bar)).data // the result of foo(bar) safely can be null/undefined
??(foo[bar]).data // foo[bar] safely can be null/undefined

Further extension:

??x + y // optional plus. binary operators should also be short-circuited.
??x`template` // optional template string

This way we won't get 3-character-combined ?.[. (if there was a single character that could be safely used.)

What do you think? Too surprising syntax to use? Is this previously proposed? Possible syntactic problem? Too much spec change?

[Mouvedia]

https://stackoverflow.com/q/8012003/248058

[saschanaz]

Oops, shame on me :/

[ljharb]

A prefix won’t work, because you can’t handle the use case where a.b is optional but b.c is not - ie, a?.b.c.

[saschanaz]

A bit verbose but (??a.b).c should do that. (Implementation detail is not in my head though.)

[ljharb]

That’d be very verbose in a longer chain that has intermixed optional and required lookups. I’m not sure how that’d be better than a multi character token?

[saschanaz]

Oops, I think I misunderstood your comment. ??a.b.c should just work because the intention here is a can safely be null/undefined, the property access chain should be short-circuited if a is nullish.. And then ??a.??b.c allows both a and a.b to be nullish.

I have to admit that this may be confusing with the current ?. proposal.

[claudepache]

@saschanaz If I understand your proposal correctly, it does the same thing as Optional chaining, except that you put a ?? token before the expression/property to be checked against nullity, instead of a ?. token after it. For example:

a.??b.c // a.b safely can be null/undefined
??(foo(bar)).data // the result of foo(bar) safely can be null/undefined

has the same semantics as a.b?.c and foo(bar)?.data.

I prefer to put the ?. or ??symbol after the maybe-nullish value, because it has a more natural left-to-right reading order: evaluate what is found on the left of ?, then check whether it is nullish, then either trigger short-circuiting or evaluate the rest of the chain (on the right of ?) normally.

Also:

Further extension:

??x + y // optional plus. binary operators should also be short-circuited.
??x`template` // optional template string

Optional chaining could also be extended as: x ?.+ y and x ?. `template` ; but we need use cases. The most difficult part is to get the scope of short-circuiting right, e.g. in a ?.* b + c.

[saschanaz]

it does the same thing as Optional chaining

Exactly.

Optional chaining could also be extended as: x ?.+ y and x ?. template;

I think a challenge here is that we would introduce several new operators ?.*, ?.+ etc. (if only we actually want the extensions, of course).

IMO x?. means accessing members of x if it is not nullish, but then x?.( does not really access any member of x, neither potential x?.+, x?.*, or x?.`template` do.

Instead, here, ??x means any access to x will cause short-circuiting if it is nullish and it won't change its meaning with potential further extensions.

[claudepache]

Optional chaining could also be extended as: x ?.+ y and x ?. template;

I think a challenge here is that we would introduce several new operators ?.*, ?.+ etc. (if only we actually want the extensions, of course).

Having several new operators is not an issue if the pattern is regular: as a precedent, consider the compound assignment operators: +=, *=, etc. That said, we could separate, e.g., the ”optional addition” operator (?.+) into two operators, namely an ”optional” postfix operator (?.) followed by the regular ”addition” pseudo-operator (+); however, we still need to define correct short-circuiting semantics for each case.

IMO x?. means accessing members of x if it is not nullish, but then x?.( does not really access any member of x, neither potential x?.+, x?.*, or x?.template do.

Right; for that reason, we’re going to change ?./?.[, etc. into ??./??[, etc., see #48.

[saschanaz]

however, we still need to define correct short-circuiting semantics for each case.

(Assuming we actually want optional + or anything)

+ is a binary operator so it becomes x ??+ y. What would be the behavior? Both x and y can be nullish, or only x? How could we make only y to be optional?

If we use unary operator we can do ??x + y, ??x + ??y, x + ??y. (Again I don't have any implementation detail in my mind.)

[claudepache]

+ is a binary operator so it becomes x ??+ y. What would be the behavior? Both x and y can be nullish, or only x? How could we make only y to be optional?

For the extension I was thinking of, only the LHS of the operator would be checked whether it is nullish. If we wanted, we could morph ?? into a suffix unary operator, and use it as in x?? + y?? (although it wouldn’t be ”just” an operator due to short-circuiting). We can imagine many things. But we must first consider what are the potential use cases, that is, find what are the problem before trying to solve it.

A possible extension that does have use cases, is ”optionally iterable”, or ”nullish treated as a void iterator”; and it is not about binary operators, but syntactical constructs like for/of, ..., and yield*.