{}+{} incosistency

Michał Wadas michalwadas at gmail.com
Wed Apr 13 15:22:47 UTC 2016


I can confirm - ziyunfei is right.
Chrome console treats {}+{} as ({}+{}). The first one should be parsed as
"empty block, unary plus operator, empty object literal".
({}+{}) is parsed as "empty object literal, addition operator, empty object
literal".


({}+{}) yields "[object Object][object Object]" in all major vendors.

2016-04-13 17:19 GMT+02:00 Till Schneidereit <till at tillschneidereit.net>:

> On Wed, Apr 13, 2016 at 4:32 PM, Caitlin Potter <caitpotter88 at gmail.com>
> wrote:
>
>> My read of section 12.8.3.1 (
>> https://tc39.github.io/ecma262/#sec-addition-operator-plus-runtime-semantics-evaluation
>> ),
>> is that V8 is getting this right.
>>
>> ToPrimitive on `{}` will, by default, return “[object Object]” — We first
>> call `Object.prototype.valueOf()`, which returns `this` (see 19.1.3.7).
>> Following this, we call `toString()`, and get “[object Object]”.
>>
>> Subsequent steps of the algorithm just concatenate the two strings
>> together. So it looks like the other vendors are getting this wrong?
>>
>
> I don't think that reading is right. Steps 5 and 6 call ToPrimitive
> without a PreferredType. For objects without a @@toPrimitive property, that
> ends up calling OrdinaryToPrimitive(input, "number"), which results in NaN.
> So step 7 isn't called - instead we end up running steps 8-10.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160413/3e1418dd/attachment.html>


More information about the es-discuss mailing list