Why Don't Logical Operators (&& and ||) Always Return a Boolean Result

&& (AND) and || (OR) in IF statements

No, it will not be evaluated. And this is very useful. For example, if you need to test whether a String is not null or empty, you can write:

if (str != null && !str.isEmpty()) {
  doSomethingWith(str.charAt(0));
}

or, the other way around

if (str == null || str.isEmpty()) {
  complainAboutUnusableString();
} else {
  doSomethingWith(str.charAt(0));
}

If we didn't have 'short-circuits' in Java, we'd receive a lot of NullPointerExceptions in the above lines of code.

Boolean operators && and ||

The shorter ones are vectorized, meaning they can return a vector, like this:

((-2:2) >= 0) & ((-2:2) <= 0)
# [1] FALSE FALSE  TRUE FALSE FALSE

The longer form evaluates left to right examining only the first element of each vector, so the above gives

((-2:2) >= 0) && ((-2:2) <= 0)
# [1] FALSE

As the help page says, this makes the longer form "appropriate for programming control-flow and [is] typically preferred in if clauses."

So you want to use the long forms only when you are certain the vectors are length one.

You should be absolutely certain your vectors are only length 1, such as in cases where they are functions that return only length 1 booleans. You want to use the short forms if the vectors are length possibly >1. So if you're not absolutely sure, you should either check first, or use the short form and then use all and any to reduce it to length one for use in control flow statements, like if.

The functions all and any are often used on the result of a vectorized comparison to see if all or any of the comparisons are true, respectively. The results from these functions are sure to be length 1 so they are appropriate for use in if clauses, while the results from the vectorized comparison are not. (Though those results would be appropriate for use in ifelse.

One final difference: the && and || only evaluate as many terms as they need to (which seems to be what is meant by short-circuiting). For example, here's a comparison using an undefined value a; if it didn't short-circuit, as & and | don't, it would give an error.

a
# Error: object 'a' not found
TRUE || a
# [1] TRUE
FALSE && a
# [1] FALSE
TRUE | a
# Error: object 'a' not found
FALSE & a
# Error: object 'a' not found

Finally, see section 8.2.17 in The R Inferno, titled "and and andand".

If statements and && or ||

It is entering the statement because the statement becomes true when it calculates iNumber != 9

An || (Or Operator) in an if will be true if any statement is true.

Think of it this way..

8 != 8 is False
8 != 9 is True

if ( False || True )
{
    //Do Stuff
}

Why does C# && and || operators work the way they do?

As I understand you would prefer a && b being defined as something like ((bool)a)&&((bool)b) instead of what C# uses.

But I think this kind of operator overloading was introduced to support tri-state bools such as bool? and DBBool.

Let's define a few examples for such a type:

With no short circuiting possible:

null && true == null
null && false == false
null || true == true
null || false == null

With short circuiting possible:

false && null == false
true || null == true

The basic idea here is to treat null as unknown value and return null if the result is undetermined and a bool if the result doesn't change no matter what you put into the null argument.

Now you want to define a short circuiting logical and and or on this type. If you do that using the C# true and false operators, both of which return false on a null argument you get the desired behavior. With a c like behavior you don't.

The C# designers probably didn't care about logical and/or on integers like in your example. Integers are no boolean values and as such should not offer logical operators. That bool and integer are the same thing is one of c's historic properties that a new language doesn't need to mirror. And the distinction of bitwise vs logical operators on ints only exists in c due to c's inability to distinguish booleans and integers. This distinction is unnecessary in languages which distinguish these types.

Calling & a bitwise operation is misleading in C#. The essence of && vs & isn't logical vs bitwise and. That isn't determined by which operator you use, but by which types you use. On logical types (bool, bool?, DBBool) both operators are logical, and on integer types & is bitwise and && doesn't make sense, since you can't short-circuit on integers. The essence of && vs & is that the first short-circuits and the second doesn't.

And for the cases where the operators are defined at all this coincides with the c interpretation. And since && isn't defined on integers, because that doesn't make sense with the C# interpretation of && your problem of how && is evaluated on integers does not exist.

Reason for the existence of non-short-circuit logical operators

Updated answer:

Apologies, I missed the word "logical" in your question even though it is there. (I've taken the liberty of emphasizing it a bit with an edit.)

Consider the case where you want any side-effects to always occur, regardless of whether the left-hand expression evaluates true or false. E.g., contrast:

if (foo() & bar()) {
    // Only call this if both operations returned true
}

with

if (foo() && bar()) {
    // Only call this if both operations returned true
}

Let's assume both foo and bar have effects that we want to have happen regardless of whether foo returns true or false. In the first one above, I know that bar will always get called and have its effect. In the latter, of course, bar may or may not get called. If we didn't have the non-short-circuit version, we'd have to use temporary variables:

boolean fooResult, barResult;
fooResult = foo();
barResult = bar();
if (fooResult && barResult) {
    // ...
}

You might argue (I probably would) that you should do that anyway, because it's way too easy to misread if (foo() & bar()), but there we go, a pragmatic reason for having non-short-circuit versions.

Original answer:

How would you propose & (or |) be a short-circuited operator? With && and ||, it makes sense because you're dealing with boolean conditions: They can be true or false, there are no shades of grey. But & and | deal with bits, not booleans. The result is a number. I mean, I guess & could not evaluate the right-hand side if the left-hand side were 0, and similarly | could not evaluate it if the left-hand side were all-bits-on for whatever the type was, but I don't see much point to making the one edge case of each operator significant (as compared to the 254 or more other cases).

Java logical operator (&&, ||) short-circuit mechanism

It's simply because

if (false && true || true)

is equivalent to (&& has a higher precedence)

if ((false && true) || true)

which is

if (false || true)

which is... true.

Note: In the expression true || true && false, the part true && false is called a dead code because it doesn't affect the final result of the evaluation, since true || anything is always true.

---

It is worth mentioning that there exist & and | operators that can be applied to booleans, they are much like && and || except that they don't short circuit, meaning that if you have the following expression:

if (someMethod() & anotherMethod())

and someMethod returns false, anotherMethod will still be reached! But the if won't be executed because the final result will be evaluated to false.

Using IF, AND, OR together with EQUAL operand together in Python

It helps to examine the logic of this line:

if (len(x) == (4 or 6)):

The (4 or 6) clause contains a logical or short circuit. The value 4 is true, so it is evaluated and returned to the == relational comparison.

The way that or works is that its lefthand side is evaluated for Boolean truth, and its value is returned if true. If the lefthand side is not Boolean true, then the righthand side is evaluated and its value is returned.

Because the lefthand side of the 4 or ... is true in a Boolean sense, the righthand side is never evaluated. Python doesn't even look past 4 or. If the left-hand value were a false value (such as 0), then the right hand side of the or would be evaluated.

To see this in action, try print 4 or 6. The output will be 4.

So since the 4 is a hard-coded true value, your comparison is semantically the same as if (len(x) == 4) -- that is, since 4 is true, 6 is never evaluated.

What I suppose you really want to know is if len(x) is either 4 or 6. You could put that to code in a couple of ways:

if(len(x) == 4 or len(x) == 6 ...

if(len(x) in (4,6) ...

Using nested if statements vs logical operator && in c++

For the first example, if pieceisnotonedge returns false, will it also check the next condition?

No. It will "short-circuit" because if the first condition is false, checking the conditions after it is unnecessary. Read more here and here.

This is guranteed by the C++ standard:

7.6.14

... && guarantees left-to-right evaluation: the second operand is not evaluated if the first operand is false.

Note that, for || this is opposite, that is, if the first condition is "true", then checking the conditions afterwards is unnecessary

Shall i use; or...

Both are same, if you have a short if statement (with only two conditions), I would suggest using the first approach. In terms of efficiency there is no difference and you can verify this by looking at the generated assembly for both cases on godbolt

---

Related Topics