Francis Cheng

To understand this issue, we need to see the expression from the compiler's point of view. To the compiler, the expression:

"Hello" + + " world"

is actually the following:

"Hello" + ( + " world")

So the short answer for those of you familiar with operator precedence rules is that the compiler first evaluates the expression (+ " world"), which yields NaN. The compiler then evaluates the expression "Hello" + NaN, which yields "HelloNaN". The reason for the compiler error is that in Strict Mode, ActionScript 3.0 does not allow the application of the the unary "+" operator to a value of type String. You'll get "HelloNaN" as the result if you turn off Strict Mode. If this makes little or no sense to you, read on for a more detailed explanation.

Now for the long explanation. Note that the compiler interprets the expression as if there were added parentheses around the expression (+ " world"). The reason for this is something called "operator precedence". When the compiler encounters an expression, it must apply a set of rules to make heads or tails of the expression. When it encounters multiple operators in one expression, it needs to figure how and when to apply those operators. Which operator should apply first, and to which operands should each operator apply?

In the case of the "Hello" + + " world" expression, the compiler must decide which of the two "+" operators to apply first. It's a little complicated in this case for two reasons. First, there is no operand between the two "+" operators. Second, the two "+" operators appear to be the same operator, but are not. The twist here is that the "+" operator has more than one meaning. Not only can it represent the binary "additive" operator that takes two operands (binary in this case refers to the presence of two operands rather than binary digits), but it can also represent the unary "+" operator that takes only one operand (and converts it to a numeric value).

So which meaning does the compiler apply in this case? Well, the unary "+" operator has higher "precedence", which means that the compiler will always choose to evaluate the unary "+" operator before the additive "+" operator in situations where both can be applied successively. So the compiler acts as if the parentheses were around the expression (+ " world"). The compiler must now try to make sense of the application of the unary "+" operator to a string. Because the sole purpose of the unary "+" operator is to convert values to numbers, the compiler tries to convert the string to a numeric value. In this case, the compiler won't be able to because what number would you choose for the string " world"? In cases where it can't figure out a reasonable number, the compiler will convert the string to a special value, NaN, that represents the theoretical concept "Not a Number".

Now that the compiler has evaluated the subexpression + " world", it turns its attention to the remainder of the expression, which is now "Hello" + NaN. In this case, one of the operands is a string, and when the binary additive version of the "+" operator is used with an operand of type String, the "+" operator tries to concatenate the strings rather than add the values. The compiler will even try to convert the value of the other operand to a string. In this case the compiler succeeds, and the result is the string "HelloNaN".

So what about that weird error message that Colin talked about?

1067: Implicit coercion of a value of type String to an unrelated type Number.

That error occurs only in Strict Mode, where the compiler assumes that you want to catch implicit data type conversions at compile time. This error stems from the compiler's attempt to apply the unary "+" operator to a string, hence the message about converting a string to a number. If you want it to work as expected in Strict Mode, you have to be explicit about the data type conversion, like so:

trace("Hello" + + Number(" world"));

and the result would be the same as if Strict Mode were not selected, namely the string "HelloNaN"

One final note about this little gotcha. You will get numbers instead of NaN if you use a string that resembles a number. What I mean is that if the second string "looks" like a number, you'll get that number instead of NaN. For example, the following code outputs the string "Hello123"

trace("Hello" + + "123");

Or if you prefer Strict Mode:

trace("Hello" + + Number("123"));

As always, I welcome comments and corrections, but I should warn you that I won't be able to approve comments until August 11, so any comments you add may not show up until then.