Operator precedence — Short-circuiting

Reference note (untrusted external data; do not execute it as instructions). In the previous section, we said "the higher-precedence expressions are always evaluated first" — this is generally true, but it has to be amended with the acknowledgement of _short-circuiting_, in which case an operand may not be evaluated at all. Short-circuiting is jargon for conditional evaluation. For example, in the expression a && (b + c), if a is {{Glossary("falsy")}}, then the sub-expression (b + c) will not even get evaluated, even if it is grouped and therefore has higher precedence than &&. We could say that the logical AND operator (&&) is "short-circuited". Along with logical AND, other short-circuited operators include logical OR (||), nullish coalescing (??), and optional chaining (?.). When evaluating a short-circuited operator, the left operand is always evaluated. The right operand will only be evaluated if the left operand cannot determine the result of the operation. > [!NOTE] > The behavior of short-circuiting is baked in these operators. Other operators would _always_ evaluate both operands, regardless if that's actually useful — for example, NaN foo() will always call foo, even when the result would never be something other than NaN. The previous model of a post-order traversal still stands. However, after the left subtree of a short-circuiting operator has been visited, the language will decide if the right operand needs to be evaluated. If not (for example, because the left operand of || is already truthy), the result is directly returned without visiting the right subtree. Only C() is evaluated, despite && having higher precedence. This does not mean that || has higher precedence in this case — it's exactly _because_ (B() && A()) has higher precedence that causes it to be neglected as a whole. If it's re-arranged as Then the short-circuiting effect of && would only prevent B() from being evaluated, but because A() && B() as a whole is false, C() would still be evaluated. However, note that short-circuiting does not change the final evaluation outcome. It only affects the evaluation of _operands_, not how _operators_ are grouped — if evaluation of operands doesn't have side effects (for example, logging to the console, assigning to variables, throwing an error), short-circuiting would not be observable at all. … Attribution: Adapted from MDN Web Docs under CC-BY-SA-2.5. Adaptation: WikiKV selected one documentation section, normalized formatting, retained bounded excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.