Why would a language NOT use Short-circuit evaluation?

Question

Why would a language NOT use Short-circuit evaluation? Are there any benefits of not using it?

I see that it could lead to some performances issues... is that true?

Answer 1

VB6 doesn't use short-circuit evaluation, I don't know if newer versions do, but I doubt it. I believe this is just because older versions didn't either, and because most of the people who used VB6 wouldn't expect that to happen, and it would lead to confusion.

This is just one of the things that made it extremely hard for me to get out of being a noob VB programmer who wrote spaghetti code, and get on with my journey to be a real programmer.

Answer 2

The short-circuit evaluation automatically provides conditional evaluation of a part of the expression.

The main advantage is that it simplifies the expression.

The performance could be improved but you could also observe a penalty for very simple expressions.

Another consequence is that side effects of the evaluation of the expression could be affected.

In general, relying on side-effect is not a good practice, but in some specific context, it could be the preferred solution.

Answer 3

The language Lustre does not use short-circuit evaluation. In if-then-elses, both then and else branches are evaluated at each tick, and one is considered the result of the conditional depending on the evaluation of the condition.

The reason is that this language, and other synchronous dataflow languages, have a concise syntax to speak of the past. Each branch needs to be computed so that the past of each is available if it becomes necessary in future cycles. The language is supposed to be functional, so that wouldn't matter, but you may call C functions from it (and perhaps notice they are called more often than you thought).

In Lustre, writing the equivalent of

if (y <> 0) then 100/y else 100

is a typical beginner mistake. The division by zero is not avoided, because the expression 100/y is evaluated even on cycles when y=0.

Answer 4

I'd say 99 times out of 100 I would prefer the short-circuiting operators for performance.

But there are two big reasons I've found where I won't use them. (By the way, my examples are in C where && and || are short-circuiting and & and | are not.)

1.) When you want to call two or more functions in an if statement regardless of the value returned by the first.

if (isABC() || isXYZ()) // short-circuiting logical operator
    //do stuff;

In that case isXYZ() is only called if isABC() returns false. But you may want isXYZ() to be called no matter what.

So instead you do this:

if (isABC() | isXYZ()) // non-short-circuiting bitwise operator
    //do stuff;

2.) When you're performing boolean math with integers.

myNumber = i && 8; // short-circuiting logical operator

is not necessarily the same as:

myNumber = i & 8; // non-short-circuiting bitwise operator

In this situation you can actually get different results because the short-circuiting operator won't necessarily evaluate the entire expression. And that makes it basically useless for boolean math. So in this case I'd use the non-short-circuiting (bitwise) operators instead.

Like I was hinting at, these two scenarios really are rare for me. But you can see there are real programming reasons for both types of operators. And luckily most of the popular languages today have both. Even VB.NET has the AndAlso and OrElse short-circuiting operators. If a language today doesn't have both I'd say it's behind the times and really limits the programmer.

Answer 5

Look at my example at On SQL Server boolean operator short-circuit which shows why a certain access path in SQL is more efficient if boolean short circuit is not used. My blog example it shows how actually relying on boolean short-circuit can break your code if you assume short-circuit in SQL, but if you read the reasoning why is SQL evaluating the right hand side first, you'll see that is correct and this result in a much improved access path.

Answer 6

Because short-circuiting can change the behavior of an application IE:

if(!SomeMethodThatChangesState() || !SomeOtherMethodThatChangesState())