Is an object notation brace valid in any expression?

Question

I am currently a little versed in the JavaScript language. It looks like you could group a lot of concepts into a basic type called an expression. Even arguments and function definitions fit into this group, as well as strings, numbers, and mathematical expressions. The only illogical exception was the inclusion of curly braces in stupidity in a similar context.

Since functions consist of several expressions, the following code applies:

function valid(){ /\W/; "ahll"; var alpha; alpha; alpha={"first": 90, "second": 80}; alpha; 0, {"first": 90, "second": 80}; [1,2,3]; alpha; 2+3; new RegExp("/\W/"); return true; } 

Optionally, the following code should also be valid, but it receives a syntax error "missing before before" for the second line:

 function invalid(){ {"first": 90, "second": 80}; return true; } 

The notation of curly braces is accepted in every other case when expressions are accepted, with the exception of cases when a code block of curly braces is also allowed.

Is the syntax error mentioned above caused by an implementation or javascript specification?

Is there a more accurate name for such a meaningless expression?

Answer 1

Is the syntax error mentioned above caused by an implementation or javascript specification?

According to the specification.

Is there a more accurate name for such a meaningless expression

You are looking for the term Expression Statement . As you say, object literals are expressions (even primary expressions ), like most other things. They can be displayed in many contexts, such as function arguments, operator operands, or inside brackets.

However, the body-code of the function - does not consist of expressions, it consists of operators . This means things like if-statements, loop statements, or simple blocks. Or "expressions", which are nothing more than an expression that needs to be evaluated (and with side effects they are mostly not "nonsense").

However, the specification mandates :

ExpressionStatement : [lookahead ∉ { { , function }] Expression ;

NOTE. ExpressionStatement cannot begin with opening a curly brace, because this can make it ambiguous with Block . In addition, ExpressionStatement cannot begin with the keyword function, because that can make it ambiguous with FunctionDeclaration.

Answer 2

What you are viewing as an object in the last example is actually block :

From MDN:

A block operator is used to group zero or more operators. The block is divided into a pair of curly braces.

So, basically, when you start curly braces, it realizes that it is a block, and gives an error:

 Uncaught SyntaxError: Unexpected token : 

Because he does not like these colons ( : inside the block, where he expects operators ( var a = 2 , etc.). He suggests that everything that follows the curly brace should be a set of statements, and, therefore, is surprised to find the colon and, in confusion, causes an error. Note that "first": 90 not a valid statement.

Then why 0, {"first": 90, "second": 80}; pass?

Because, having seen the first expression ( 0 ), and then the comma operator, he expects to see another value of the same type (that is, another expression). And thus, it treats the second object {"first": 90, "second": 80} as an object (which is also an expression) instead of a block.

For simplicity, try {"first": 90, "second": 80}, 0 . Note: it gives a SyntaxError exactly the same as the previous one. Since, having seen { , he considers the following as a block and again complains of a colon ( : .

How to avoid this?

By making it part of another expression, for example:

 ( {1:2} ) // a block doesn't come inside parentheses var a = {1 : 2}; // a block can't be the RHS myFunc( { 1 : 5 } ) // a block can't be a function argument 

Hope this helps!

Answer 3

This was discussed in a previous question here.

Curly braces are used either to enter a statement block or to start an object literal. To deal with this ambiguity, curly braces are interpreted as the container of the statement block by default, so there is a syntax error in your example.

When braces are used in an RHS statement, the ambiguity disappears; This is an object literal.

Answer 4

The analyzer has priority for processing { as the beginning of a block, and not for the beginning of an object.

So, what are we doing to explicitly tell the reader to add first before multiplication, in the case of:

 3 * 4 + 2 

Perhaps it:

 3 * (4 + 2) 

Similarly for

 {"first": 90, "second": 80}; 

we could do it either

 ({"first": 90, "second": 80}); 

or put it in various ways when the parser understands your true intent.

Answer 5

ECMA-262 defines different types of expressions. The "expression" mentioned in the first question corresponds to the best PrimaryExpression, which is described as follows: (each indented line is a possible representation)

 PrimaryExpresion: this //as the 'this'-keyword Identifier //variable or function name ('alpha' in the question) Literal //string, number, mathematical expressions ArrayLiteral //[1,2,3] ObjectLiteral // {"first" : 80} ( Expression ) //An expression encapsulated in bracket 

Brown code block:

 Block : { StatementList_opt } - A list of statements 

The most relevant expression in this case:

 ExpressionStatement : [lookahead ∉ {{, function}] Expression ; 

This allows only an expression without an opening brace or the keyword 'function' at the beginning. (FunctionDeclarations are separate from statements and expressions, with the exception of lambda functions, which are FunctionExpression)

In the definition of an expression, the primary expression is not directly indicated, but, along a long chain of definitions, the primary expression can be considered as an expression:

 Expression: AssignmentExpression Expression, AssingmentExpression 

I checked the entire definition chain to see if PrimaryExpression is actually an expression. Here is the definition chain:

 Expression: AssignmentExpression: ConditionalExpression: LogicalORExpression: LogicalANDExpression: BitwiseORExpression: BitwiseXORExpression: BitwiseANDExpression: EuqalityExpression: RelationalExpression: ShiftExpressions: AdditiveExpression: MultiplicativeExpression: UnaryExpression: PostfixExpression: LeftHandSideExpression: NewExpression: MemberExpression: PrimaryExpression: 

To answer the question

The curly-bracket lens attribute specified as ObjectLiteral in ECMA-262 is , by definition, valid in each expression, unless the expression in Statement has been explicitly expressed because ExpressionStatement explicitly prevents the opening curly bracket from appearing as the first character of the expression to resolve a conflict with the code a brace block (defined as Block). FunctionBody, Block, Program (global scope) and all loop constructions (IterationStatements) use instructions and therefore have restrictions to contain only blocks, not ObjectLiterals in the code section.

Finally

The specification restricts curly braces to represent either a block of code or an object notation. Curly braces are considered a code block wherever the use of the word "var" is allowed, and vice versa.