What does it mean: if (a=b)

[Tom de Neef]

My Pascal background results in one type of error that I make all the time:
using "=" instead of "==" in the conditional tests of if statements.
So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What then
does it do? Assign the value of b to a and then test if a is defined?
Tom

 

[D. Stussy]

My Pascal background results in one type of error that I make all the time:
using "=" instead of "==" in the conditional tests of if statements.
So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What then
does it do? Assign the value of b to a and then test if a is defined?
Tom

Assign the value from b to a: Yes.
Test if a is defined: Yes, but also tests if zero or not zero.

 

[Ivan Marsh]

My Pascal background results in one type of error that I make all the
time: using "=" instead of "==" in the conditional tests of if
statements. So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What
then does it do? Assign the value of b to a and then test if a is
defined? Tom

Assign the value of "a" to "b", did that operation fail? No, therefore a=b
evaluates to true.

 

[Ivan Marsh]

Assign the value of "a" to "b", did that operation fail? No, therefore
a=b evaluates to true.

Oops... pardon me, strike that, reverse it.

Assign the value of "b" to "a"...

 

[Joost Diepenmaat]

Assign the value of "a" to "b", did that operation fail? No, therefore a=b
evaluates to true.

It just returns the value of "b" after assinging it to "a". There's no
such thing as "failing to assign", though the assignment could be
ignored (which is not checked) or it could throw an exception (which
would not return anything in the usual sense).

 

[Matt Kruse]

Assign the value of "a" to "b", did that operation fail? No, therefore a=b
evaluates to true.

Be careful...
The return value of an assignment operation is the value assigned, not
a boolean indicating whether or not it succeeded.

(a=b)

will be false for any value of be that is "falsey".

Matt Kruse

 

[Joost Diepenmaat]

It just returns the value of "b" after assinging it to "a". There's no
such thing as "failing to assign", though the assignment could be
ignored (which is not checked) or it could throw an exception (which
would not return anything in the usual sense).

Quick fix: read "evaluate(s) to" instead of "return(s)" and "assigning"
instead of "assinging".

 

[Stevo]

My Pascal background results in one type of error that I make all the time:
using "=" instead of "==" in the conditional tests of if statements.
So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What then
does it do? Assign the value of b to a and then test if a is defined?
Tom

It's just a shortcut for the following code:

a=b
if(a)

or in other words, assign it and test it ... if(a=b)

It's not testing whether a and b are the same. It's testing the
truthiness of a, after it gets assigned the value from b.

 

[Tom Cole]

You should be writing

     if (a === b) {
         ...
     }

Yes, not one, not two, but three equal signs. JSLint can help you get it right.

http://www.JSLint.com/

Just for future reference (in case someone sumbles across this post in
the future)
a === b does a comparison (just like ==) but without a data
conversion.

For example:

alert("3" == 5-2);

Will alert "true", whereas

alert("3" === 5-2);

Will alert "false"

 

[Stevo]

it assigns the value of b to a, and the "if" part will always return true
because you can ALWAYS assign the value of b to a.

That's nonsense.

 

[Ivan Marsh]

It just returns the value of "b" after assinging it to "a". There's no
such thing as "failing to assign", though the assignment could be
ignored (which is not checked) or it could throw an exception (which
would not return anything in the usual sense).

Indeed... I'm not suggesting that it would ever fail, it will always
evaluate to true.

 

[Joost Diepenmaat]

Indeed... I'm not suggesting that it would ever fail, it will always
evaluate to true.

It won't if b == false

 

[Ivan Marsh]

Be careful...
The return value of an assignment operation is the value assigned, not a
boolean indicating whether or not it succeeded.

(a=b)

will be false for any value of be that is "falsey".

Is that correct?

It's my understanding that the question that's being asked by if is a
boolean question.

The if would be evaluating the outcome of the expression not the value the
expression ends up with. The if would then be evaluating the assignment as
being true because the assignment was successful not the value of a.

if (a=b) would therefore always evaluate to true.

If that's an incorrect understanding it's definitely something I should
have in mind.

 

[Joost Diepenmaat]

Is that correct?

Yes. Ecma-262,

11.13.1 Simple Assignment ( = )
The production AssignmentExpression : LeftHandSideExpression =
AssignmentExpression is evaluated as follows:
1. Evaluate LeftHandSideExpression.
2. Evaluate AssignmentExpression.
3. Call GetValue(Result(2)).
4. Call PutValue(Result(1), Result(3)).
5. Return Result(3).

It's my understanding that the question that's being asked by if is a
boolean question.

That's not relevant. Javascript expressions have no concept of
context. The assignment expression is evaluated first, and the result of
the assignment (which the value of the expression on the *right* hand side of
the assignment operator) is then evaluated as a boolean.

The if would be evaluating the outcome of the expression not the value the
expression ends up with. The if would then be evaluating the assignment as
being true because the assignment was successful not the value of a.

if (a=b) would therefore always evaluate to true.

If that's an incorrect understanding it's definitely something I should
have in mind.

It's incorrect. Keep it in mind

 

[Ivan Marsh]

Is that correct?

It's my understanding that the question that's being asked by if is a
boolean question.

The if would be evaluating the outcome of the expression not the value
the expression ends up with. The if would then be evaluating the
assignment as being true because the assignment was successful not the
value of a.

if (a=b) would therefore always evaluate to true.

If that's an incorrect understanding it's definitely something I should
have in mind.

Just answered my own question with a little but of code... well, that
sucks.

That's going to take a while to unlearn.

 

[Matt Kruse]

Just answered my own question with a little but of code... well, that
sucks.

It's actually quite useful for doing things like this:

var e,i=0;
while (e=arr[i++])
... do something with e ...

As long as your array does not contain falsey values.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

My Pascal background results in one type of error that I make all the time:
using "=" instead of "==" in the conditional tests of if statements.
So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What then
does it do? Assign the value of b to a and then test if a is defined?

That depends.

In JavaScript 1.2 (NN 4.0 to 4.05), before JavaScript was fully compatible
with ECMAScript Ed. 1, it meant that the following statement was only
executed if the assignment-converted-into-a-comparison resulted in a
true-value (you still can trigger that behavior with <script
language="JavaScript1.2"> in NN 4.06+).

In later implementations that comply with ECMAScript Ed. 1 and later, it
means instead that the following statement is executed if `a' evaluates to a
true-value after the value of `b' has been assigned to it.

http://developer.mozilla.org/en/doc...n_JavaScript_Versions_and_ECMAScript_Editions
http://developer.mozilla.org/en/doc..._Assignment_within_the_conditional_expression
http://docs.sun.com/source/816-6408-10/stmt.htm#1004833

Since the implementation you are dealing with is unknown, the recommendation
is not to use the aforementioned `language' attribute (inconsistent
interpretation of its value is the reason why it was deprecated), and either
not to write assignments in `if' statements (other programming languages
such as Python have adopted this as a language rule due to the ambiguity) --

a = b;
if (a) ...

--, or to enclose the assignment in another pair of parentheses:

if ((a = b)) ...


PointedEars

 

[Thomas 'PointedEars' Lahn]

You should be writing

if (a === b) {
...
}

Yes, not one, not two, but three equal signs.

That depends. `===' is not supported before JavaScript 1.3, ECMAScript Ed.
3, and it does not perform type conversion which sometimes may be desired.

http://PointedEars.de/scripts/es-matrix/

JSLint can help you get it right.

http://www.JSLint.com/

And JSLint may give the wrong recommendation in some cases.


PointedEars

 

[Joost Diepenmaat]

That depends.

In JavaScript 1.2 (NN 4.0 to 4.05), before JavaScript was fully compatible
with ECMAScript Ed. 1, it meant that the following statement was only
executed if the assignment-converted-into-a-comparison resulted in a
true-value (you still can trigger that behavior with <script
language="JavaScript1.2"> in NN 4.06+).

In later implementations that comply with ECMAScript Ed. 1 and later, it
means instead that the following statement is executed if `a' evaluates to a
true-value after the value of `b' has been assigned to it.

This is not true for Ecma-262, ed. 3 at least; there, the statement will
be executed if *b* evaluates to true after it's been assigned to a,
since the assigment evaluates to b.

 

[Thomas 'PointedEars' Lahn]

My Pascal background results in one type of error that I make all the time:
using "=" instead of "==" in the conditional tests of if statements.
So, i write if (a=b) ...

It doesn't do what I want, but it appears to be acceptable code. What then
does it do? Assign the value of b to a and then test if a is defined?

That depends.
[...]
In later implementations that comply with ECMAScript Ed. 1 and later, it
means instead that the following statement is executed if `a' evaluates to a
true-value after the value of `b' has been assigned to it.

This is not true for Ecma-262, ed. 3 at least; there, the statement will
be executed if *b* evaluates to true after it's been assigned to a,
since the assigment evaluates to b.

I stand corrected (ES 1 to 3, 11.13.1, 3.) Thanks.


PointedEars