Short-circuit evaluation

In any programming language that implements short-circuit evaluation, the expression x and y is equivalent to the conditional expression if x then y else x, and the expression x or y is equivalent to if x then x else y. In either case, x is only evaluated once.

The generalized definition above accommodates loosely typed languages that have more than the two truth-values True and False, where short-circuit operators may return the last evaluated subexpression. This is called "last value" in the table below. For a strictly-typed language, the expression is simplified to if x then y else false and if x then true else y respectively for the boolean case.

Although {{code|AND}} takes precedence over {{code|OR}} in many languages, this is not a universal property of short-circuit evaluation. An example of the two operators taking the same precedence and being left-associative with each other is POSIX shell's command-list syntax.{{cite web |title=Shell Command Language |url=https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html |website=pubs.opengroup.org}}{{rp|at=§2.9.3}}

The following simple left-to-right evaluator enforces a precedence of {{code|AND}} over {{code|OR}} by a {{code|continue}}:

function short-circuit-eval (operators, values)

let result := True

for each (op, val) in (operators, values):

if op = "AND" && result = False

continue

else if op = "OR" && result = True

return result

else

result := val

return result

Short-circuit logic, with or without side-effects, have been formalized based on Hoare's conditional. A result is that non-short-circuiting operators can be defined out of short-circuit logic to have the same sequence of evaluation.{{cite arXiv |last1=Bergstra |first1=Jan A. |last2=Ponse |first2=A. |last3=Staudt |first3=D.J.C. |date=2010 |title=Short-circuit logic |eprint=1010.3674|class=cs.LO}}

The following table is restricted to common programming languages and the basic boolean operators for logical conjunction AND and logical disjunction OR. In some languages, the bitwise operators can be used as eager boolean operators. For other languages, bitwise operators are not included in the list, because they do not take boolean values or have a result type different from the respective short-circuit operators.

Note that there are more short-circuit operators, for example the ternary conditional operator, which is cond ? e1 : e2 (C, C++, Java, PHP), if cond then e1 else e2 (ALGOL, Haskell, Kotlin, Rust), e1 if cond else e2 (Python). Please take a look at ternary conditional operator#Usage.

{{notelist}}

Usual example, using a C-based language:

int denom = 0;

if (denom != 0 && num / denom)

{

... // ensures that calculating num/denom never results in divide-by-zero error

}

Consider the following example:

int a = 0;

if (a != 0 && myfunc(b))

{

do_something();

}

In this example, short-circuit evaluation guarantees that myfunc(b) is never called. This is because a != 0 evaluates to false. This feature permits two useful programming constructs.

1. If the first sub-expression checks whether an expensive computation is needed and the check evaluates to false, one can eliminate expensive computation in the second argument.
2. It permits a construct where the first expression guarantees a condition without which the second expression may cause a run-time error.

Both are illustrated in the following C snippet where minimal evaluation prevents both null pointer dereference and excess memory fetches:

bool is_first_char_valid_alpha_unsafe(const char *p)

{

return isalpha(p[0]); // SEGFAULT highly possible with p == NULL

}

bool is_first_char_valid_alpha(const char *p)

{

return p != NULL && isalpha(p[0]); // 1) no unneeded isalpha() execution with p == NULL, 2) no SEGFAULT risk

}

Since minimal evaluation is part of an operator's semantic definition and not an optional optimization, a number of coding idioms rely on it as a succinct conditional construct. Examples include:

Perl idioms:

some_condition or die; # Abort execution if some_condition is false

some_condition and die; # Abort execution if some_condition is true

POSIX shell idioms:{{cite web |url=https://unix.stackexchange.com/questions/190543/what-does-mean-in-bash |title=What does {{!}}{{!}} mean in bash? |publisher=stackexchange.com |access-date=2019-01-09}}

modprobe -q some_module && echo "some_module installed" || echo "some_module not installed"

This idiom presumes that echo cannot fail.

Despite these benefits, minimal evaluation may cause problems for programmers who do not realize (or forget) it is happening. For example, in the code

if (expressionA && myfunc(b)) {

do_something();

}

if myfunc(b) is supposed to perform some required operation regardless of whether do_something() is executed, such as allocating system resources, and expressionA evaluates as false, then myfunc(b) will not execute, which could cause problems. Some programming languages, such as Java, have two operators, one that employs minimal evaluation and one that does not, to avoid this problem.

Problems with unperformed side effect statements can be easily solved with proper programming style, i.e., not using side effects in boolean statements, as using values with side effects in evaluations tends to generally make the code opaque and error-prone.{{cite web |url=http://www.itu.dk/people/sestoft/papers/SondergaardSestoft1990.pdf |title=Referential Transparency, Definiteness and Unfoldability |publisher=Itu.dk |access-date=2013-08-24}}

Short-circuiting can lead to errors in branch prediction on modern central processing units (CPUs), and dramatically reduce performance. A notable example is highly optimized ray with axis aligned box intersection code in ray tracing.{{clarify|date=November 2010}} Some compilers can detect such cases and emit faster code, but programming language semantics may constrain such optimizations.{{citation needed|date=October 2016}}

An example of a compiler unable to optimize for such a case is Java's Hotspot virtual machine (VM) as of 2012.{{cite web |last=Wasserman |first=Louis |date=11 July 2012 |title=Java: What are the cases in which it is better to use unconditional AND (& instead of &&) |url=https://stackoverflow.com/a/11412121 |website=Stack Overflow}}

• Don't-care term
• Null coalescing operator
• Ternary conditional operator

{{Reflist}}

{{John McCarthy}}

Category:Articles with example C code

Category:Articles with example Perl code

Category:Compiler optimizations

Category:Conditional constructs

Category:Evaluation strategy

Category:Implementation of functional programming languages