Ответ 1

Chrome devtools теперь автоматически переносит все, что начинается с { и заканчивается } в неявной паре скобок (см. код), чтобы заставить его оценивать как выражение. Таким образом, {} создает пустой объект. Вы можете увидеть это, если вернуться к истории ( ↑), предыдущая строка будет содержаться в (...).

Почему? Я не знаю, но Я мог догадаться, что это уменьшает путаницу для новичков, которые не знают об объекте block-vs-object-literal, и это также более полезно, если вы просто хотите оценить выражение.

И на самом деле это рассуждение, как описано в ошибке 499864. Чистое удобство. И поскольку node REPL имел его (см. код).

Ответ 2

Если вы нажмете стрелку вверх после ее проверки, вы заметите, что вместо {} + {} отображается ({} + {}), что приводит к "[object Object][object Object]".

Для сравнения, в Firefox {} + {} по-прежнему отображается NaN, но если вы делаете ({} + {}), то также отображается "[object Object][object Object]".

Итак, похоже, что Chrome добавляет окружающие круглые скобки автоматически, когда видит эту операцию.

Ответ 3

Начиная с Chrome 54 относительно консоли:

К сожалению, я добавил цитату Clippy. Консоль не дает информации о том, что она сделала для вас.

Новые правила невероятно просто спасают нас от тяжелой работы с этими двумя сложными символами o= или 0, перед тем, как вставить в Линейку Object Literals:

• Если у вас есть код, который начинается с: необязательного пробела (без комментариев), за которым следует {;
• и этот код может быть интерпретирован как объект;
• и за этим объектом не следует никакого другого кода, если:
• код после первого объекта является двоичным оператором,
• тогда может быть столько операций, сколько вам нужно, включая группировки
• если конечный оператор имеет литерал Object в правой позиции;
• и что последний объект не был сгруппирован в parens
• и этот код не заканчивается точкой с запятой
• и комментариев нет после кода (внутренние комментарии разрешены до тех пор, пока они не находятся в начальной или конечной позиции)
• тогда и только тогда ваш JavaScript (который может или не может быть действительно действительным кодом) будет повторно интрмирован как действительный объект. Вы не будете проинформированы о том, что ваш код был переинтерпретирован.

{wat:1}),({wat:2} Наконец, ошибка снова.

{let i=0;var increment=_=>i++} правильно разрешено, наконец, это довольно хороший способ сделать закрытие.

Однако, неверно, это объект, это просто удобство, о котором упоминается @Bergi, оно интерпретирует JS неправильно, чтобы помочь вам! Спецификация говорит, что это блок с помеченным выражением "foo" с литеральным 1, который ничем не назначен.

{foo:1}

Вышеуказанное должно быть таким же, как

if(1) {
    foo: 1
}

Следующее обрабатывается правильно как блок... потому что перед ним есть комментарий!

//magic comment
{foo:1}

Вот так:

{foo:1}
//also magic

Это объект:

{foo:
//not so magic comment
1}

Это ошибка

//not so magic comment
{foo:1}.foo

Вот так:

{foo:1}.foo

Это нормально:

1..wat

undefined

и так:

['foo'][0]

Следующий корректно интерпретируется как объект, удаленный в позицию выражения с помощью 0,, который обычно является тем, как мы однозначно гарантируем, что у нас есть выражение вместо выражения.

0,{foo:1}.foo

Я не понимаю, почему они переносят значение в parens. У JS есть некоторые смешные дизайнерские решения, но попытка заставить его вести себя лучше в этой ситуации, на самом деле это не вариант, консоль должна правильно запускать JS, и нам нужно быть уверенным, что хром не просто догадывается, что он думает, что мы действительно означало, что он сделал что-то еще.

Если вам не нравятся операторы запятой, вы можете использовать назначение

x = {foo:1}.foo

Потому что, поскольку он стоит

{} + {} + {}

"[object Object][object Object][object Object]"

;{} + {} + {}

"NaN[object Object]"

Сумасшедший и последовательный я могу справиться... сумасшедший и непоследовательный нет спасибо!