6

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?

  • `&&` 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. – Jon Hanna Feb 02 '16 at 23:05

1 Answers1

8

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.)

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • That's it! I knew that I've overlooked something. Thanks! –  Feb 02 '16 at 22:43
  • 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? – mrmcgreg Feb 02 '16 at 22:44
  • For things like "options || {}" it is much more readable to use the idiomatic "||" than to use the ternary operator. – m4ktub Feb 02 '16 at 22:44
  • @mrmcgreg it's the execution thing; sorry, I didn't word that clearly. – Pointy Feb 02 '16 at 22:45
  • 1
    Why can't the engine optimize this? Because of possible site effects within the function? –  Feb 02 '16 at 22:54
  • It's quite possible the engine does optimise it, as long as it optimises any side-effects or guarantees there are none. – Jon Hanna Feb 02 '16 at 22:59
  • @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. – Pointy Feb 02 '16 at 23:01
  • @JonHanna I guess side effects are the reason why lazy evaluation doesn't work in Javascript. That is a good example. –  Feb 02 '16 at 23:06
  • 1
    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. – Jon Hanna Feb 02 '16 at 23:08