This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
logical operators in java
What's the difference between | and || in Java?
As the title says, I need to know the difference between & operator and && operator.
Can anyone help me in simple words.
How do they differ from each other?
And which one to be used in a IF statement?
There are in fact three "and" operators:
a && b, with a and b being boolean: evaluate a. If true, evaluate b. If true, result is true. Otherwise, result is false. (I.e. b is not evaluated if a is not true.)
a & b, with a and b being boolean: evaluate both, do logical and (i.e. true only if both are true).
a & b, where a and b are both integral types (int, long, short, char, byte): evaluate a and b, and do a bitwise AND.
The second one can be viewed as a special type of the third one, if one sees boolean as a one-bit integral type ;-)
As the top-level condition of an if-statement you can use the first two, but the first one is most likely useful. (I.e. there are not many cases where you really need the second and the first would do something wrong, but the other way around is more common. In most cases the first is simply a little bit faster.)
If the first result is FALSE, && doesn't evaluate the second result. & does.
&& only evaluates the second expression if the first operation is true. & evaluates both expressions (even if the first expression is false and there is no point in evaluating the second expression). Hence && is a tiny bit faster than & in logical operations. Hence && is also known as short-circuit and.
& can also be used as a bitwise operator in addition to a logical operator. So you can do a 'Bit And' of 2 numbers like for example
int result = 1 & 3; // will evaluate to 1
&& cannot be used as a bit-and operator.
For conditional IF operator, use &&. It is a tiny bit faster than just &.
Related
In JavaScript and Java, the equals operator (== or ===) has a higher precedence than the OR operator (||). Yet both languages (JS, Java) support short-circuiting in if statements:
When we have if(true || anything()), anything() isn't evaluated.
You can also have the following expression: true || foo == getValue()) - for example in an output statement such as console.log(...);, or in an assignment.
Now, according to operator precedence, short-circuiting shouldn't happen, as === = == > || in terms of precedence. (In other words, the comparison should happen first, for which getValue() ought to be called, as the equality check has a higher precedence that the OR comparison.) But it does. getValue() isn't called (as can easily be checked by putting an output statement into its body).
Why (does short circuiting work when the operator precedence says it shouldn't)?
Or am I confusing matters?
Or am I confusing matters?
You are. I think it's much simpler to think about precedence as grouping than ordering. It affects the order of evaluation, but only because it changes the grouping.
I don't know about Javascript for sure, but in Java operands are always evaluated in left-to-right order. The fact that == has higher precedence than || just means that
true || foo == getValue()
is evaluated as
true || (foo == getValue())
rather than
(true || foo) == getValue()
If you just think about precedence in that way, and then consider that evaluation is always left-to-right (so the left operand of || is always evaluated before the right operand, for example) then everything's simple - and getValue() is never evaluated due to short-circuiting.
To remove short-circuiting from the equation, consider this example instead:
A + B * C
... where A, B and C could just be variables, or they could be other expressions such as method calls. In Java, this is guaranteed to be evaluated as:
Evaluate A (and remember it for later)
Evaluate B
Evaluate C
Multiply the results of evaluating B and C
Add the result of evaluating A with the result of the multiplication
Note how even though * has higher precedence than +, A is still evaluated before either B or C. If you want to think of precedence in terms of ordering, note how the multiplication still happens before the addition - but it still fulfills the left-to-right evaluation order too.
According to the language specification, https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.24
At run time, the left-hand operand expression is evaluated first; if the result has type Boolean, it is subjected to unboxing conversion (§5.1.8).
If the resulting value is true, the value of the conditional-or expression is true and the right-hand operand expression is not evaluated.
So if you have a || b==c, it is not interpreted as (a || b) == c, because || has lower precedence, as you found in the tutorial. Instead, it is interpreted as a || (b==c). Now since a is the left side of ||, it is evaluated first.
There is no operator precedence in this case. What you are questioning is like in f(callback) statement the callback function being evaluated even before f. This can not happen.
On the other hand, in JS the || is one of the few places where you can watch laziness at show. The == operand (think as if it is an infix function like in fully functional languages) takes two arguments and the one on the left gets evaluated first. If it resolves to true the second argument doesn't even get evaluated.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference in & and &&
if (true && true) {
System.out.println("test if");
}
if (true & true) {
System.out.println("test if");
}
both are give same output.why ?
&& short-circuits, wheras & doesn't. Example:
if (methodA() && methodB()) {
...
}
In that case, if methodA already returns false, methodB is not called. Formally, if you have an expression a && b, b is only evaluated if a evaluated to true.
Apart from the obvious performance benefit, this is particularly useful for null checks:
if (x != null && x.getSomeValue()) {
...
}
If you used a s single & here, x.getSomeValue() would be evaluated even if x were null, resulting in an exception.
& is a bit operation
&& logically links two booleans
Please see:
http://www.jguru.com/faq/view.jsp?EID=16530
It depends on the type of the arguments...
For integer arguments, the single ampersand ("&")is the "bit-wise AND"
operator. The double ampersand ("&&") is not defined for anything but
two boolean arguments.
For boolean arguments, the single ampersand constitutes the
(unconditional) "logical AND" operator while the double ampersand
("&&") is the "conditional logical AND" operator. That is to say that
the single ampersand always evaluates both arguments whereas the
double ampersand will only evaluate the second argument if the first
argument is true.
For all other argument types and combinations, a compile-time error
should occur.
In the first case, you don't test the second part of the if : the && operator executes from left to right and stops at the first false value.
This may be useful in this case :
if (a!=null && a.doSomething()==23) {
because it prevents a nullPointerException.
When you test boolean conditions, always use &&.
In & statetment it will check both left side and right side statements.in && will check only one side of statement(if one side is true it will not check other side)
&& is the logical AND
so you want to make sure BOTH statements become true.
& is the bitwise AND operator
Have a look here:
http://www.javaforstudents.co.uk/TrueFalse
&& is logical and.
true && true is true and everything else is false.
& is bitwise and.
(10 & 8) = 8
Firstly I learnt that &, |, ^ are the bitwise operators, and now somebody mentioned them as logical operators with &&, ||, I am completely confused - the same operator has two names? There are already logical operators &&, ||, then why use &, |, ^?
The Java operators &, | and ^ are EITHER bitwise operators OR logical operators ... depending on the types of the operands. If the operands are integers, the operators are bitwise. If they are booleans, then the operators are logical.
And this is not just me saying this. The JLS describes these operators this way too; see JLS 15.22.
(This is just like + meaning EITHER addition OR string concatenation ... depending on the types of the operands. Or just like a "rose" meaning either a flower or a shower attachment. Or "cat" meaning either a furry animal or a UNIX command. Words mean different things in different contexts. And this is true for the symbols used in programming languages too.)
There are already logical operators &&, ||, why use &, |, ^?
In the case of the first two, it is because the operators have different semantics with regards to when / whether the operands get evaluated. The two different semantics are needed in different situations; e.g.
boolean res = str != null && str.isEmpty();
versus
boolean res = foo() & bar(); // ... if I >>need<< to call both methods.
The ^ operator has no short-circuit equivalent because it simply doesn't make sense to have one.
Having a language reference is one thing, interpreting it correctly is another.
We need to interpret things correctly.
Even if Java documented that & is both bitwise and logical, we could make an argument that & really didn't lost its logical-operator-ness mojo since time immemorial, since C. That is, & is first and foremost, an inherently logical operator(albeit a non-short-circuited one at that)
& parses lexically+logically as logical operation.
To prove the point, both of these lines behaves the same, eversince C and upto now(Java, C#, PHP, etc)
if (a == 1 && b)
if (a == 1 & b)
That is, the compiler will interpret those as these:
if ( (a == 1) && (b) )
if ( (a == 1) & (b) )
And even if both variables a and b are both integers. This...
if (a == 1 & b)
... will still be interpereted as:
if ( (a == 1) & (b) )
Hence, this will yield a compilation error on languages which doesn't facilitate integer/boolean duality, e.g. Java and C#:
if (a == 1 & b)
In fact, on the compilation error above, we could even make an argument that & didn't lost its logical(non-short-circuit) operation mojo, and we can conclude that Java continues the tradition of C making the & still a logical operation. Consequently, we could say it's the other way around, i.e. the & can be repurposed as bitwise operation (by applying parenthesis):
if ( a == (1 & b) )
So there we are, in another parallel universe, someone could ask, how to make the & expression become a bitmask operation.
How to make the following compile, I read in JLS that & is a bitwise
operation. Both a and b are integers, but it eludes me why the
following bitwise operation is a compilation error in Java:
if (a == 1 & b)
Or this kind of question:
Why the following didn't compile, I read in JLS that & is a bitwise
operation when both its operands are integers. Both a and b are
integers, but it eludes me why the following bitwise operation is a
compilation error in Java:
if (a == 1 & b)
In fact, I would not be surprised if there's already an existing stackoverflow questions similar to above questions that asked how to do that masking idiom in Java.
To make that logical operation interpretation by the language become bitwise, we have to do this (on all languages, C, Java, C#, PHP, etc):
if ( a == (1 & b) )
So to answer the question, it's not because JLS defined things such way, it's because Java(and other languages inspired by C)'s & operator is for all intents and purposes is still a logical operator, it retained C's syntax and semantics. It's the way it is since C, since time immemorial, since before I was even born.
Things just don't happen by chance, JLS 15.22 didn't happen by chance, there's a deep history around it.
In another parallel universe, where && was not introduced to the language, we will still be using & for logical operations, one might even ask a question today:
Is it true, we can use the logical operator & for bitwise operation?
& doesn't care if its operands are integers or not, booleans or not. It's still a logical operator, a non-short-circuited one. And in fact, the only way to force it to become a bitwise operator in Java(and even in C) is to put parenthesis around it. i.e.
if ( a == (1 & b) )
Think about it, if && was not introduced to C language(and any language who copied its syntax and semantics), anyone could be asking now:
how to use & for bitwise operations?
To sum it up, first and foremost Java & is inherently a logical operator(a non-short-circuited one), it doesn't care about its operands, it will do its business as usual(applying logical operation) even if both operands are integers(e.g. masking idiom). You can only force it to become bitwise operation by applying parenthesis. Java continues the C tradition
If Java's & really is a bitwise operation if its operands(integer 1 and integer variable b on example code below) are both integers, this should compile:
int b = 7;
int a = 1;
if (a == 1 & b) ...
They(& and |) were used for two purposes long time ago, logical operator and bitwise operator. If you'll check out the neonatal C (the language Java was patterned after), & and | were used as logical operator.
But since disambiguating the bitwise operations from logical operations in the same statement is very confusing, it prompted Dennis Ritchie to create a separate operator(&& and ||) for logical operator.
Check the Neonatal C section here: http://cm.bell-labs.com/who/dmr/chist.html
You can still use the bitwise operators as logical operators, its retained operator precedence is the evidence of that. Read out the history of bitwise operator's past life as logical operator on Neonatal C
Regarding the evidence, I made a blog post on comparing the logical operator and bitwise operator. It will be self-evident that the so called bitwise operators are still logical operators if you try contrasting them in an actual program: http://www.anicehumble.com/2012/05/operator-precedence-101.html
I also answered a question related to your question on What is the point of the logical operators in C?
So it's true, bitwise operators are logical operators too, albeit non-short-circuited version of short-circuited logical operators.
Regarding
There are already logical operators &&, ||, then why use &, |, ^?
The XOR can be easily answered, it's like a radio button, only one is allowed, code below returns false. Apology for the contrived code example below, the belief that drinking both beer and milk at the same time is bad was debunked already ;-)
String areYouDiabetic = "Yes";
String areYouEatingCarbohydrate = "Yes";
boolean isAllowed = areYouDiabetic == "Yes" ^ areYouEatingCarbohydrate == "Yes";
System.out.println("Allowed: " + isAllowed);
There's no short-circuit equivalent to XOR bitwise operator, as both sides of the expression are needed be evaluated.
Regarding why the need to use & and | bitwise operators as logical operators, frankly you'll be hard-pressed to find a need to use bitwise operators(a.k.a. non-short-circuit logical operators) as logical operators. A logical operation can be non-short-circuited (by using the bitwise operator, aka non-short-circuited logical operator) if you want to achieve some side effect and make your code compact(subjective), case in point:
while ( !password.isValid() & (attempts++ < MAX_ATTEMPTS) ) {
// re-prompt
}
The above can re-written as the following(removing the parenthesis), and still has exactly the same interpretation as the preceding code.
while ( !password.isValid() & attempts++ < MAX_ATTEMPTS ) {
// re-prompt
}
Removing the parenthesis and yet it still yields the same interpretation as the parenthesized one, can make the logical operator vestige of & more apparent. To run the risk of sounding superfluous, but I have to emphasize that the unparenthesized expression is not interpreted as this:
while ( ( !password.isValid() & attempts++ ) < MAX_ATTEMPTS ) {
// re-prompt
}
To sum it up, using & operator (more popularly known as bitwise operator only, but is actually both bitwise and logical(non-short-circuited)) for non-short-circuit logical operation to achieve side effect is clever(subjective), but is not encouraged, it's just one line of savings effect in exchange for readability.
Example sourced here: Reason for the exsistance of non-short-circuit logical operators
The Java type byte is signed which might be a problem for the bitwise operators. When negative bytes are extended to int or long, the sign bit is copied to all higher bits to keep the interpreted value. For example:
byte b1=(byte)0xFB; // that is -5
byte b2=2;
int i = b1 | b2<<8;
System.out.println((int)b1); // This prints -5
System.out.println(i); // This prints -5
Reason: (int)b1 is internally 0xFFFB and b2<<8 is 0x0200 so i will be 0xFFFB
Solution:
int i = (b1 & 0xFF) | (b2<<8 & 0xFF00);
System.out.println(i); // This prints 763 which is 0x2FB
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why do we usually use || not |, what is the difference?
Can I use single ampersand like & instead of a bitwise operator like &&? What kind of differences may arise and is there a specific example to illustrate this issue clearly?
The single & will check both conditions always. The double && will stop after the first condition if it evaluates to false. Using two is a way of "short circuiting" the condition check if you truly only need 1 condition of 2 to be true or false.
An example could be:
if (myString != null && myString.equals("testing"))
If myString is null, the first condition would fail and it would not bother to check the value of it. This is one way you can avoid null pointers.
with & and ¦ both operands are always evaluated
with && and ¦¦ the second operand is only evaluated when it is necessary
Here's a link to a page with a pretty good explanation of how to use these.
Java Quick Reference on Operators
The other answers are correct to an extent, but don't explain the whole thing.
First off, the doubled operators, && and ||, function sort of like nested if statements:
if (expression_a && expression_b) {
do_something;
}
is equivalent to
if (expression_a) {
if (expression_b) {
do_something;
}
}
In both cases, if expression_a evaluates to false then expression_b will not be evaluated -- a feature referred to as "short-circuiting". (The || case is similar but a hair more complicated.)
Additionally, in Java (but not in C/C++) the && and || operators apply only to boolean values -- you cannot use && or || on an int, eg.
The single operators, & and |, on the other hand, are relatively "pure" operators (commutative and associative with respect to themselves), with none of the "short-circuiting" of the double operators. Additionally, they can operate on any integer type -- boolean, char, byte, short, int, long. They perform a bit-by-bit operation -- bit N of the left operand is ANDed or ORed with bit N of the right operand to produce the Nth bit in a result value that is the same bit width as the two operands (after they are widened as appropriate for binary operators). In this regard, their operation with boolean is just the degenerate case (albeit one that is somewhat special-cased).
Normally, one would use only the doubled operators for combining boolean expressions in an if statement. There is no great harm in using the single operators if the boolean expressions involved are "safe" (cannot result in a null pointer exception, eg), but the doubled operators tend to be slightly more efficient and the short-circuiting is often desired (as in if (a != null && a.b == 5), eg), so it's generally wise to cultivate the habit of using the doubled forms. The only thing to beware of is that if you want the second expression to be evaluated (for it's side-effects), the doubled operator will not guarantee this happens.
So for binary operators on booleans, Java has &, |, ^, && and ||.
Let's summarize what they do briefly here:
JLS 15.22.2 Boolean Logical Operators &, ^, and |
JLS 15.23 Conditional-And Operator &&
JLS 15.24 Conditional-Or Operator ||
For &, the result value is true if both operand values are true; otherwise, the result is false.
For |, the result value is false if both operand values are false; otherwise, the result is true.
For ^, the result value is true if the operand values are different; otherwise, the result is false.
The && operator is like & but evaluates its right-hand operand only if the value of its left-hand operand is true.
The || operator is like |, but evaluates its right-hand operand only if the value of its left-hand operand is false.
Now, among all 5, 3 of those have compound assignment versions, namely |=, &= and ^=. So my question is obvious: why doesn't Java provide &&= and ||= as well? I find that I need those more than I need &= and |=.
And I don't think that "because it's too long" is a good answer, because Java has >>>=. There must be a better reason for this omission.
From 15.26 Assignment Operators:
There are 12 assignment operators; [...] = *= /= %= += -= <<= >>= >>>= &= ^= |=
A comment was made that if &&= and ||= were implemented, then it would be the only operators that do not evaluate the right hand side first. I believe this notion that a compound assignment operator evaluates the right hand side first is a mistake.
From 15.26.2 Compound Assignment Operators:
A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.
As proof, the following snippet throws a NullPointerException, not an ArrayIndexOutOfBoundsException.
int[] a = null;
int[] b = {};
a[0] += b[-1];
Reason
The operators &&= and ||= are not available on Java because for most of the developers these operators are:
error-prone
useless
Example for &&=
If Java allowed &&= operator, then that code:
bool isOk = true; //becomes false when at least a function returns false
isOK &&= f1();
isOK &&= f2(); //we may expect f2() is called whatever the f1() returned value
would be equivalent to:
bool isOk = true;
if (isOK) isOk = f1();
if (isOK) isOk = f2(); //f2() is called only when f1() returns true
This first code is error-prone because many developers would think f2() is always called whatever the f1() returned value. It is like bool isOk = f1() && f2(); where f2() is called only when f1() returns true.
If the developer wants f2() to be called only when f1() returns true, therefore the second code above is less error-prone.
Else &= is sufficient because the developer wants f2() to be always called:
Same example but for &=
bool isOk = true;
isOK &= f1();
isOK &= f2(); //f2() always called whatever the f1() returned value
Moreover, the JVM should run this above code as the following one:
bool isOk = true;
if (!f1()) isOk = false;
if (!f2()) isOk = false; //f2() always called
Compare && and & results
Are the results of operators && and & the same when applied on boolean values?
Let's check using the following Java code:
public class qalcdo {
public static void main (String[] args) {
test (true, true);
test (true, false);
test (false, false);
test (false, true);
}
private static void test (boolean a, boolean b) {
System.out.println (counter++ + ") a=" + a + " and b=" + b);
System.out.println ("a && b = " + (a && b));
System.out.println ("a & b = " + (a & b));
System.out.println ("======================");
}
private static int counter = 1;
}
Output:
1) a=true and b=true
a && b = true
a & b = true
======================
2) a=true and b=false
a && b = false
a & b = false
======================
3) a=false and b=false
a && b = false
a & b = false
======================
4) a=false and b=true
a && b = false
a & b = false
======================
Therefore YES we can replace && by & for boolean values ;-)
So better use &= instead of &&=.
Same for ||=
Same reasons as for &&=:
operator |= is less error-prone than ||=.
If a developer wants f2() not to be called when f1() returns true, then I advice the following alternatives:
// here a comment is required to explain that
// f2() is not called when f1() returns false, and so on...
bool isOk = f1() || f2() || f3() || f4();
or:
// here the following comments are not required
// (the code is enough understandable)
bool isOk = false;
if (!isOK) isOk = f1();
if (!isOK) isOk = f2(); //f2() is not called when f1() returns false
if (!isOK) isOk = f3(); //f3() is not called when f1() or f2() return false
if (!isOK) isOk = f4(); //f4() is not called when ...
Probably because something like
x = false;
x &&= someComplexExpression();
looks like it ought to be assigning to x and evaluating someComplexExpression(), but the fact that the evaluation hinges on the value of x isn't apparent from the syntax.
Also because Java's syntax is based on C, and no one saw a pressing need to add those operators. You'd probably be better off with an if statement, anyway.
It is this way in Java, because it is this way in C.
Now the question why it is so in C is because when & and && became different operators (sometime preceding C's descent from B), the &= variety of operators was simply overlooked.
But the second part of my answer does not have any sources to back it up.
Largely because Java syntax is based on C (or at least the C family), and in C all those assignment operators get compiled to arithmetic or bitwise assembly instructions on a single register. The assignment-operator version avoids temporaries and may have produced more efficient code on early non-optimising compilers. The logical operator (as they are termed in C) equivalents (&&= and ||=) don't have such an obvious correspondence to single assembly instructions; they usually expand to a test and branch sequence of instructions.
Interestingly, languages like ruby do have ||= and &&=.
Edit: terminology differs between Java and C
One of Java's original aims was to be "Simple, Object Oriented, and Familiar." As applied to this case, &= is familiar (C, C++ have it and familiar in this context meant familiar to someone who knows those two).
&&= would not be familiar, and it would not be simple, in the sense that the language designers were not looking to think of every operator they could add to the language, so less extra operators are simpler.
For Boolean vars, && and || would use short circuit evaluation while & and | don't, so you would expect &&= and ||= to also use short circuit evaluation. There is a good use case for this. Especially if you are iterating over a loop, you want to be fast, efficient and terse.
Instead of writing
foreach(item in coll)
{
bVal = bVal || fn(item); // not so elegant
}
I want to write
foreach(item in coll)
{
bVal ||= fn(item); // elegant
}
and know that once bVal is true, fn() will not be called for the remainder of the iterations.
'&' and '&&' are not the same as '&&' is a short cut operation which will not do if the first operand is false while '&' will do it anyway (works with both number and boolean).
I do agree that it make more sense to exist but it is not that bad if it is not there. I guess it was not there because C does not have it.
Really can't think of why.
Brian Goetz (Java Language Architect at Oracle) wrote:
https://stackoverflow.com/q/2324549/ [this question] shows that there is interest in having these operators and there
are no clear arguments why they don't exist yet.
The question is therefore: Has the JDK team discussed adding these operators in the past and if so
what where the reasons against adding them?
I'm not aware of any specific discussion on this particular issue, but
if someone were to propose it, the answer would likely be: it's not an
unreasonable request, but it doesn't carry its weight.
"Carrying its weight" needs to be judged by its costs and benefits, and
by its cost-benefit ratio relative to other candidate features.
I think you are implicitly assuming (by the phrase "there is interest")
that the cost is near zero and the benefit is greater than zero, so it
seems an obvious win. But this belies an incorrect understanding of
cost; a feature like this affects the language spec, the implementation,
the JCK, and every IDE and Java textbook. There are no trivial language
features. And the benefit, while nonzero, is pretty small.
Secondarily, there are infinitely many features we could do, but we
only have capacity to do a handful every few years (and users have a
limited capacity to absorb new features.) So we have to be very careful
as to which we pick, as each feature (even a trivial-seeming one)
consumes some of this budget, and invariably takes it away from others.
It's not "why not this feature", but "what other features will we not do
(or delay) so we can do this one, and is that a good trade?" And I
can't really imagine this being a good trade against anything else we're
working on.
So, it clears the bar of "not a terrible idea" (which is already pretty
good, a lot of feature requests don't even clear that), but seems
unlikely to ever clear the bar of "a better use of our evolution budget
than anything else."
It is allowed in Ruby.
If I were to guess, I would say that it is not frequently used so it wasn't implemented. Another explanation could be that the parser only looks at the character before the =
I cannot think of any better reason then 'It looks incredible ugly!'
&
verifies both operands, it's a bitwise operator. Java defines several bitwise operators, which can be applied to the integer types, long, int, short, char, and byte.
&&
stops evaluating if the first operand evaluates to false since the result will be false, it's a logical operator. It can be applied to booleans.
The && operator is similar to the & operator, but can make your code a bit more efficient. Because both expressions compared by the & operator must be true for the entire expression to be true, there’s no reason to evaluate the second expression if the first one returns false. The & operator always evaluates both expressions. The && operator evaluates the second expression only if the first expression is true.
Having a &&= assignment operator wouldn't really add new functionality to the language. The bitwise operator's arithmetic is much more expressive, you can do integer bitwise arithmetic, which includes Boolean arithmetic. The logical operators can merely do Boolean arithmetic.
Funny I came across this question.
The operators ||= and &&= do not exist as their semantics are easily misunderstood;
if you think you need them, use an if-statement instead.
Ely (post just above) got the gist right:
||
stops evaluating if the first operand evaluates to true since the result will be true, it's a logical operator.
So imagine what will happen if b == true;
b ||= somethingreturningaboolean(); // !!??
this will not invoke somethingreturningaboolean(), if b == true.
This behavior is more obvious in the long form:
b = b || somethingreturningaboolean();
That's why ||= and &&= ops do not exist. The explanation should be given as:
The operators ||= and &&= do not exist as their semantics are easily misunderstood;
if you think you need them, use an if-statement instead.