Can the ternary operator be equivalent to short circuiting with the logical operators?

Question

With short circuiting you can prevent the evaluation of part of an expression:

let x = "", y = 123;
x && alert("foo"); // ""
y || alert("bar") // 123

Since the logical ops form expressions you can use them in function invocations or return statements.

But ultimately, that's nothing more than conditional branching and can be easily reached with the ternary operator:

x ? alert("foo") : x; // ""
y ? y : alert("bar"); // 123

This is more readable and similarly concise. Is there a reason to utilize the short circuiting property of the logical operators except for the illustrative term?

Luellaluelle

&& and || were designed as special forms of & and |, optimised for particular cases. For people used to thinking in terms of boolean arithmetic, x ? y : x for x && y would be far less readable, as well as the side-effect issue and their not being quite like that in C from which Javascript inherited them. – Pedagogics

Answer 1

It's true (well, almost true) that

x ? x : y

is logically equivalent to

x || y

However, they're not equivalent in terms of what happens when the code runs. In the ? : case, the sub-expression x may be evaluated twice. In x || y, it's definitely only evaluated once. For simple variable references, that doesn't matter, but if x is a function call, it might affect behavior and it'll certainly affect performance.

(The fact that one of the expressions might be evaluated twice is what I meant by "almost" in the first sentence.)

Samothrace

That's it! I knew that I've overlooked something. Thanks! – Luellaluelle

I'd be interested to know what the 'almost true' part of the logical equivalence is. Is there a circumstance when one of the expressions is true and the other isn't? – Audile

For things like "options || {}" it is much more readable to use the idiomatic "||" than to use the ternary operator. – Lw

@Audile it's the execution thing; sorry, I didn't word that clearly. – Samothrace

Why can't the engine optimize this? Because of possible site effects within the function? – Luellaluelle

It's quite possible the engine does optimise it, as long as it optimises any side-effects or guarantees there are none. – Pedagogics

@JonHanna that's true, but such analysis can be pretty complicated. If the sub-expression involves a function call, it's really unlikely that the runtime can guarantee the code doesn't expect a side-effect. Recall that the JavaScript optimization stuff doesn't have the time budget of something like an optimizing C++ compiler. – Samothrace

@JonHanna I guess side effects are the reason why lazy evaluation doesn't work in Javascript. That is a good example. – Luellaluelle

Yeah, but to answer "why can't the engine?" we have to start with "who said it couldn't?". I wouldn't be surprised if some do when the operand is a single variable or if some do when the operand is a literal. I wouldn't be surprised if none do either though, since it wouldn't be a big hit. – Pedagogics