Syntax
yield
yield
yield
It is a Syntax Error if the code matched by this production is contained in strict
mode code and the StringValue of Identifier is "arguments"
or
"eval"
.
IdentifierReference : yield
BindingIdentifier :
yield
LabelIdentifier :
yield
It is a Syntax Error if the code matched by this production is contained in strict mode code.
IdentifierReference[Yield] : Identifier
BindingIdentifier[Yield] : Identifier
LabelIdentifier[Yield] :
Identifier
It is a Syntax Error if this production has a [Yield] parameter and StringValue of Identifier is "yield"
.
It is a Syntax Error if this phrase is contained in strict mode code and the
StringValue of IdentifierName is: "implements"
, "interface"
,
"let"
, "package"
, "private"
, "protected"
, "public"
,
"static"
, or "yield"
.
It is a Syntax Error if StringValue of IdentifierName is the same String value as the
StringValue of any ReservedWord except for yield
.
NOTE StringValue of IdentifierName normalizes any Unicode escape sequences in IdentifierName hence such escapes cannot be used to write an Identifier whose code point sequence is the same as a ReservedWord.
See also: 13.3.1.2, 13.3.2.1, 13.3.3.1, 13.7.5.2, 14.1.3, 14.2.2, 14.4.2, 14.5.2, 15.2.2.2, 15.2.3.2.
yield
"yield"
.See also: 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
"eval"
or "arguments"
, return false.yield
IdentifierReference : yield
BindingIdentifier :
yield
LabelIdentifier :
yield
"yield"
.With arguments value and environment.
NOTE undefined is passed for environment to indicate that a PutValue operation should be used to assign the initialization value. This is the case for
var
statements and formal parameter lists of some non-strict functions (See 9.2.12). In those cases a lexical binding is hoisted and preinitialized
prior to evaluation of its initializer.
yield
"yield"
, value,
environment).yield
"yield"
).NOTE 1 The result of evaluating an IdentifierReference is always a value of type Reference.
NOTE 2 In non-strict code, the keyword yield
may be used as an identifier. Evaluating the IdentifierReference production resolves the binding
of yield
as if it was an Identifier. Early Error restriction ensures that such an
evaluation only can occur for non-strict code. See 13.3.1 for the handling of yield
in binding creation contexts.
this
(
Expression[In, ?Yield] )
(
)
(
...
BindingIdentifier[?Yield] )
(
Expression[In, ?Yield] ,
...
BindingIdentifier[?Yield] )
When processing the production
PrimaryExpression[Yield] : CoverParenthesizedExpressionAndArrowParameterList[?Yield]
the interpretation of CoverParenthesizedExpressionAndArrowParameterList is refined using the following grammar:
(
Expression[In, ?Yield] )
(
Expression[In, ?Yield] )
See also: 14.1.8, 14.2.7, 14.4.7, 14.5.6.
See also: 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
this
See also: 12.3.1.4.
this
See also: 12.1.3, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
this
this
Keywordthis
See 12.1 for IdentifierReference.
false
.true
.NOTE An ArrayLiteral is an expression describing the initialization of an Array object, using a list, of zero or more expressions each of which represents an array element, enclosed in square brackets. The elements need not be literals; they are evaluated each time the array initializer is evaluated.
Array elements may be elided at the beginning, middle or end of the element list. Whenever a comma in the element list is not preceded by an AssignmentExpression (i.e., a comma at the beginning or after another comma), the missing array element contributes to the length of the Array and increases the index of subsequent elements. Elided array elements are not defined. If an element is elided at the end of an array, that element does not contribute to the length of the Array.
[
Elisionopt ]
[
ElementList[?Yield] ]
[
ElementList[?Yield] ,
Elisionopt ]
,
Elisionopt AssignmentExpression[In, ?Yield],
Elisionopt SpreadElement[?Yield],
,
...
AssignmentExpression[In, ?Yield],
,
With parameters array and nextIndex.
,
Elisionopt AssignmentExpression,
Elisionopt SpreadElement...
AssignmentExpressionNOTE CreateDataProperty is used to ensure that own properties are defined for the array even if the standard built-in Array prototype object has been modified in a manner that would preclude the creation of new own properties using [[Set]].
[
Elisionopt ]
"length"
, pad, false).[
ElementList ]
"length"
, len, false).[
ElementList ,
Elisionopt ]
"length"
, ToUint32(padding+len), false).NOTE 1 An object initializer is an expression describing the initialization of an Object, written in a form resembling a literal. It is a list of zero or more pairs of property keys and associated values, enclosed in curly brackets. The values need not be literals; they are evaluated each time the object initializer is evaluated.
{
}
{
PropertyDefinitionList[?Yield] }
{
PropertyDefinitionList[?Yield] ,
}
,
PropertyDefinition[?Yield]:
AssignmentExpression[In, ?Yield][
AssignmentExpression[In, ?Yield] ]
=
AssignmentExpression[?In, ?Yield]NOTE 2 MethodDefinition is defined in 14.3.
NOTE 3 In certain contexts, ObjectLiteral is used as a cover grammar for a more restricted secondary grammar. The CoverInitializedName production is necessary to fully cover these secondary grammars. However, use of this production results in an early Syntax Error in normal contexts where an actual ObjectLiteral is expected.
In addition to describing an actual object initializer the ObjectLiteral productions are also used as a cover grammar for ObjectAssignmentPattern (12.14.5). and may be recognized as part of a CoverParenthesizedExpressionAndArrowParameterList. When ObjectLiteral appears in a context where ObjectAssignmentPattern is required the following Early Error rules are not applied. In addition, they are not applied when initially parsing a CoverParenthesizedExpressionAndArrowParameterList.
NOTE This production exists so that ObjectLiteral can serve as a cover grammar for ObjectAssignmentPattern (12.14.5). It cannot occur in an actual object initializer.
With parameter symbol.
See also: 14.3.2, 14.4.3, 14.5.5.
With parameter symbol.
See also: 5.3, 12.3.1.1, 14.1.4, 14.2.3, 14.4.4, 14.5.4.
NOTE Static semantic rules that depend upon substructure generally do not look into function definitions.
,
PropertyDefinition:
AssignmentExpressionSee also: 14.3.6, 14.4.10, 14.5.12
:
AssignmentExpression[
AssignmentExpression ]
,
PropertyDefinition{
}
{
PropertyDefinitionList }
{
PropertyDefinitionList ,
}
[
AssignmentExpression ]
With parameter object and enumerable.
See also: 14.3.9, 14.4.13, B.3.1
,
PropertyDefinition:
AssignmentExpression"name"
).NOTE An alternative semantics for this production is given in B.3.1.
See 14.1 for PrimaryExpression : FunctionExpression .
See 14.4 for PrimaryExpression : GeneratorExpression .
See 14.5 for PrimaryExpression : ClassExpression .
It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points other than "g"
, "i"
,
"m"
, "u"
, or "y"
, or if it contains the same code point more than once.
With parameter raw.
See also: 12.3.6.1
The abstract operation GetTemplateObject is called with a grammar production, templateLiteral, as an argument. It performs the following steps:
"frozen"
)."raw"
, PropertyDescriptor{[[Value]]:
rawObj, [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]:
false})."frozen"
).NOTE 1 The creation of a template object cannot result in an abrupt completion.
NOTE 2 Each TemplateLiteral in the program code of a Realm is associated with a unique template object that is used in the evaluation of tagged Templates (12.2.9.5). The template objects are frozen and the same template object is used each time a specific tagged Template is evaluated. Whether template objects are created lazily upon first evaluation of the TemplateLiteral or eagerly prior to first evaluation is an implementation choice that is not observable to ECMAScript code.
NOTE 3 Future editions of this specification may define additional non-enumerable properties of template objects.
NOTE 1 The string conversion semantics applied to the Expression
value are like String.prototype.concat
rather than the
+
operator.
NOTE 2 The string conversion semantics applied to the Expression
value are like String.prototype.concat
rather than the
+
operator.
NOTE 3 The string conversion semantics applied to the Expression
value are like String.prototype.concat
rather than the
+
operator.
It is a Syntax Error if the lexical token sequence matched by CoverParenthesizedExpressionAndArrowParameterList cannot be parsed with no tokens left over using ParenthesizedExpression as the goal symbol.
All Early Errors rules for ParenthesizedExpression and its derived productions also apply to CoveredParenthesizedExpression of CoverParenthesizedExpressionAndArrowParameterList.
See also: 12.2.1.3, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
(
Expression )
See also: 12.1.3, 12.2.1.5, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
(
Expression )
(
Expression )
NOTE This algorithm does not apply GetValue to the result of
evaluating Expression. The principal motivation for this is so that operators such as
delete
and typeof
may be applied to parenthesized expressions.
[
Expression[In, ?Yield] ]
.
IdentifierNamenew
MemberExpression[?Yield] Arguments[?Yield]super
[
Expression[In, ?Yield] ]
super
.
IdentifierNamenew
.
target
new
NewExpression[?Yield][
Expression[In, ?Yield] ]
.
IdentifierNamesuper
Arguments[?Yield](
)
(
ArgumentList[?Yield] )
...
AssignmentExpression[In, ?Yield],
AssignmentExpression[In, ?Yield],
...
AssignmentExpression[In, ?Yield]With parameter symbol.
See also: 5.3, 12.2.6.3, 14.1.4, 14.2.3, 14.4.4, 14.5.4
.
IdentifierNamesuper
.
IdentifierNamesuper
, return true..
IdentifierNameSee also: 12.2.1.3, 12.2.10.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
[
Expression ]
.
IdentifierNamenew
MemberExpression Argumentsnew
NewExpression[
Expression ]
.
IdentifierNameSee also: 13.7.5.6.
[
Expression ]
.
IdentifierNamenew
MemberExpression Argumentsnew
NewExpression[
Expression ]
.
IdentifierNameSee also: 12.2.1.4.
[
Expression ]
.
IdentifierNamenew
MemberExpression Argumentsnew
NewExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
[
Expression ]
.
IdentifierName[
Expression ]
.
IdentifierNamenew
NewExpressionnew
MemberExpression Argumentsnew
.
target
NOTE Properties are accessed by name, using either the dot notation:
.
IdentifierName.
IdentifierNameor the bracket notation:
[
Expression ]
[
Expression ]
The dot notation is explained by the following syntactic conversion:
.
IdentifierNameis identical in its behaviour to
[
<identifier-name-string> ]
and similarly
.
IdentifierNameis identical in its behaviour to
[
<identifier-name-string> ]
where <identifier-name-string> is the result of evaluating StringValue of IdentifierName.
[
Expression ]
.
IdentifierName[
Expression ]
Is evaluated in exactly the same manner as MemberExpression : MemberExpression [
Expression ]
except that the contained CallExpression is evaluated in step 1.
.
IdentifierNameIs evaluated in exactly the same manner as MemberExpression : MemberExpression .
IdentifierName except that the contained CallExpression is evaluated
in step 1.
new
Operatornew
NewExpressionnew
MemberExpression ArgumentsThe abstract operation EvaluateNew with arguments constructProduction, and arguments performs the following steps:
"eval"
, then
A CallExpression evaluation that executes step 4.a.vii is a direct eval.
The abstract operation EvaluateCall takes as arguments a value ref, a syntactic grammar production arguments, and a Boolean argument tailPosition. It performs the following steps:
The abstract operation EvaluateDirectCall takes as arguments a value func, a value thisValue, a syntactic grammar production arguments, and a Boolean argument tailPosition. It performs the following steps:
super
Keywordsuper
[
Expression ]
super
.
IdentifierNamesuper
ArgumentsThe abstract operation GetSuperConstructor performs the following steps:
The abstract operation MakeSuperPropertyReference with arguments propertyKey and strict performs the following steps:
See also: 12.2.9.2
(
)
...
AssignmentExpression,
AssignmentExpression,
...
AssignmentExpressionnew
.
target
++
--
++
--
It is an early Reference Error if IsValidSimpleAssignmentTarget of LeftHandSideExpression is false.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8
++
--
See also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
++
--
++
1
to oldValue, using the same rules as for
the +
operator (see 12.7.5).--
1
from oldValue, using the same rules
as for the -
operator (12.7.5).delete
UnaryExpression[?Yield]void
UnaryExpression[?Yield]typeof
UnaryExpression[?Yield]++
UnaryExpression[?Yield]--
UnaryExpression[?Yield]+
UnaryExpression[?Yield]-
UnaryExpression[?Yield]~
UnaryExpression[?Yield]!
UnaryExpression[?Yield]++
UnaryExpression--
UnaryExpressionIt is an early Reference Error if IsValidSimpleAssignmentTarget of UnaryExpression is false.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
delete
UnaryExpressionvoid
UnaryExpressiontypeof
UnaryExpression++
UnaryExpression--
UnaryExpression+
UnaryExpression-
UnaryExpression~
UnaryExpression!
UnaryExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
delete
UnaryExpressionvoid
UnaryExpressiontypeof
UnaryExpression++
UnaryExpression--
UnaryExpression+
UnaryExpression-
UnaryExpression~
UnaryExpression!
UnaryExpressiondelete
Operatordelete
UnaryExpressionIt is a Syntax Error if the UnaryExpression is contained in strict mode code and the derived UnaryExpression is PrimaryExpression : IdentifierReference.
It is a Syntax Error if the derived UnaryExpression is
PrimaryExpression : CoverParenthesizedExpressionAndArrowParameterList
and CoverParenthesizedExpressionAndArrowParameterList ultimately derives a phrase that, if used in place
of UnaryExpression, would produce a Syntax Error according to these rules. This rule is recursively
applied.
NOTE The last rule means that expressions such as
delete
(((foo)))
produce early errors because of recursive application of the first rule.
delete
UnaryExpressionNOTE When a delete
operator occurs within strict
mode code, a SyntaxError exception is thrown if its UnaryExpression is a direct
reference to a variable, function argument, or function name. In addition, if a delete
operator occurs
within strict mode code and the property to be deleted has the attribute {
[[Configurable]]: false }, a TypeError exception is thrown.
void
Operatorvoid
UnaryExpressionNOTE GetValue must be called even though its value is not used because it may have observable side-effects.
typeof
Operatortypeof
UnaryExpression"undefined"
.Type of val | Result |
---|---|
Undefined | "undefined" |
Null | "object" |
Boolean | "boolean" |
Number | "number" |
String | "string" |
Symbol | "symbol" |
Object (ordinary and does not implement [[Call]]) | "object" |
Object (standard exotic and does not implement [[Call]]) | "object" |
Object (implements [[Call]]) | "function" |
Object (non-standard exotic and does not implement [[Call]]) | Implementation-defined. Must not be "undefined" , "boolean" , "function" , "number" , "symbol" , or "string". |
NOTE Implementations are discouraged from defining new typeof
result values for
non-standard exotic objects. If possible "object"
should be used for such objects.
++
UnaryExpression1
to oldValue, using the same rules as for
the +
operator (see 12.7.5).--
UnaryExpression1
from oldValue, using the same
rules as for the -
operator (see
12.7.5).+
OperatorNOTE The unary + operator converts its operand to Number type.
+
UnaryExpression-
OperatorNOTE The unary -
operator converts its operand to Number type and then negates
it. Negating +0 produces −0, and negating −0 produces +0.
-
UnaryExpression~
)~
UnaryExpression!
)!
UnaryExpression*
/
%
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
MultiplicativeExpression : MultiplicativeExpression MultiplicativeOperator UnaryExpression
See also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
MultiplicativeExpression : MultiplicativeExpression MultiplicativeOperator UnaryExpression
MultiplicativeExpression : MultiplicativeExpression MultiplicativeOperator UnaryExpression
*
OperatorThe *
MultiplicativeOperator performs multiplication, producing the product of its
operands. Multiplication is commutative. Multiplication is not always associative in ECMAScript, because of finite
precision.
The result of a floating-point multiplication is governed by the rules of IEEE 754-2008 binary double-precision arithmetic:
If either operand is NaN, the result is NaN.
The sign of the result is positive if both operands have the same sign, negative if the operands have different signs.
Multiplication of an infinity by a zero results in NaN.
Multiplication of an infinity by an infinity results in an infinity. The sign is determined by the rule already stated above.
Multiplication of an infinity by a finite nonzero value results in a signed infinity. The sign is determined by the rule already stated above.
In the remaining cases, where neither an infinity nor NaN is involved, the product is computed and rounded to the nearest representable value using IEEE 754-2008 round-to-nearest mode. If the magnitude is too large to represent, the result is then an infinity of appropriate sign. If the magnitude is too small to represent, the result is then a zero of appropriate sign. The ECMAScript language requires support of gradual underflow as defined by IEEE 754-2008.
/
OperatorThe /
MultiplicativeOperator performs division, producing the quotient of its
operands. The left operand is the dividend and the right operand is the divisor. ECMAScript does not perform integer
division. The operands and result of all division operations are double-precision floating-point numbers. The result of
division is determined by the specification of IEEE 754-2008 arithmetic:
If either operand is NaN, the result is NaN.
The sign of the result is positive if both operands have the same sign, negative if the operands have different signs.
Division of an infinity by an infinity results in NaN.
Division of an infinity by a zero results in an infinity. The sign is determined by the rule already stated above.
Division of an infinity by a nonzero finite value results in a signed infinity. The sign is determined by the rule already stated above.
Division of a finite value by an infinity results in zero. The sign is determined by the rule already stated above.
Division of a zero by a zero results in NaN; division of zero by any other finite value results in zero, with the sign determined by the rule already stated above.
Division of a nonzero finite value by a zero results in a signed infinity. The sign is determined by the rule already stated above.
In the remaining cases, where neither an infinity, nor a zero, nor NaN is involved, the quotient is computed and rounded to the nearest representable value using IEEE 754-2008 round-to-nearest mode. If the magnitude is too large to represent, the operation overflows; the result is then an infinity of appropriate sign. If the magnitude is too small to represent, the operation underflows and the result is a zero of the appropriate sign. The ECMAScript language requires support of gradual underflow as defined by IEEE 754-2008.
%
OperatorThe %
MultiplicativeOperator yields the remainder of its operands from an implied
division; the left operand is the dividend and the right operand is the divisor.
NOTE In C and C++, the remainder operator accepts only integral operands; in ECMAScript, it also accepts floating-point operands.
The result of a floating-point remainder operation as computed by the %
operator is not the same as the
“remainder” operation defined by IEEE 754-2008. The IEEE 754-2008 “remainder” operation computes
the remainder from a rounding division, not a truncating division, and so its behaviour is not analogous to that of the
usual integer remainder operator. Instead the ECMAScript language defines %
on floating-point operations to
behave in a manner analogous to that of the Java integer remainder operator; this may be compared with the C library
function fmod.
The result of an ECMAScript floating-point remainder operation is determined by the rules of IEEE arithmetic:
If either operand is NaN, the result is NaN.
The sign of the result equals the sign of the dividend.
If the dividend is an infinity, or the divisor is a zero, or both, the result is NaN.
If the dividend is finite and the divisor is an infinity, the result equals the dividend.
If the dividend is a zero and the divisor is nonzero and finite, the result is the same as the dividend.
In the remaining cases, where neither an infinity, nor a zero, nor NaN is involved, the floating-point remainder r from a dividend n and a divisor d is defined by the mathematical relation r = n − (d × q) where q is an integer that is negative only if n/d is negative and positive only if n/d is positive, and whose magnitude is as large as possible without exceeding the magnitude of the true mathematical quotient of n and d. r is computed and rounded to the nearest representable value using IEEE 754-2008 round-to-nearest mode.
+
MultiplicativeExpression[?Yield]-
MultiplicativeExpression[?Yield]See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
+
MultiplicativeExpression-
MultiplicativeExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
+
MultiplicativeExpression-
MultiplicativeExpression+
)NOTE The addition operator either performs string concatenation or numeric addition.
+
MultiplicativeExpressionNOTE 1 No hint is provided in the calls to ToPrimitive in steps 7 and 9. All standard objects except Date objects handle the absence of a hint as if the hint Number were given; Date objects handle the absence of a hint as if the hint String were given. Exotic objects may handle the absence of a hint in some other manner.
NOTE 2 Step 11 differs from step 5 of the Abstract Relational Comparison algorithm (7.2.11), by using the logical-or operation instead of the logical-and operation.
-
)-
MultiplicativeExpressionThe +
operator performs addition when applied to two operands of numeric type, producing the sum of the
operands. The -
operator performs subtraction, producing the difference of two numeric operands.
Addition is a commutative operation, but not always associative.
The result of an addition is determined using the rules of IEEE 754-2008 binary double-precision arithmetic:
If either operand is NaN, the result is NaN.
The sum of two infinities of opposite sign is NaN.
The sum of two infinities of the same sign is the infinity of that sign.
The sum of an infinity and a finite value is equal to the infinite operand.
The sum of two negative zeroes is −0. The sum of two positive zeroes, or of two zeroes of opposite sign, is +0.
The sum of a zero and a nonzero finite value is equal to the nonzero operand.
The sum of two nonzero finite values of the same magnitude and opposite sign is +0.
In the remaining cases, where neither an infinity, nor a zero, nor NaN is involved, and the operands have the same sign or have different magnitudes, the sum is computed and rounded to the nearest representable value using IEEE 754-2008 round-to-nearest mode. If the magnitude is too large to represent, the operation overflows and the result is then an infinity of appropriate sign. The ECMAScript language requires support of gradual underflow as defined by IEEE 754-2008.
NOTE The -
operator performs subtraction when applied to two operands of numeric
type, producing the difference of its operands; the left operand is the minuend and the right operand is the subtrahend.
Given numeric operands a and b, it is always the case that a–
b produces the same result as
a +(–
b)
.
<<
AdditiveExpression[?Yield]>>
AdditiveExpression[?Yield]>>>
AdditiveExpression[?Yield]See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
<<
AdditiveExpression>>
AdditiveExpression>>>
AdditiveExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
<<
AdditiveExpression>>
AdditiveExpression>>>
AdditiveExpression<<
)NOTE Performs a bitwise left shift operation on the left operand by the amount specified by the right operand.
<<
AdditiveExpression>>
)NOTE Performs a sign-filling bitwise right shift operation on the left operand by the amount specified by the right operand.
>>
AdditiveExpression>>>
)NOTE Performs a zero-filling bitwise right shift operation on the left operand by the amount specified by the right operand.
>>>
AdditiveExpressionNOTE 1 The result of evaluating a relational operator is always of type Boolean, reflecting whether the relationship named by the operator holds between its two operands.
<
ShiftExpression[?Yield]>
ShiftExpression[?Yield]<=
ShiftExpression[? Yield]>=
ShiftExpression[?Yield]instanceof
ShiftExpression[?Yield]in
ShiftExpression[?Yield]NOTE 2 The [In] grammar parameter is needed to avoid confusing the in
operator in
a relational expression with the in
operator in a for
statement.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
<
ShiftExpression>
ShiftExpression<=
ShiftExpression>=
ShiftExpressioninstanceof
ShiftExpressionin
ShiftExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
<
ShiftExpression>
ShiftExpression<=
ShiftExpression>=
ShiftExpressioninstanceof
ShiftExpressionin
ShiftExpression<
ShiftExpression>
ShiftExpression<=
ShiftExpression>=
ShiftExpressioninstanceof
ShiftExpressionin
ShiftExpressionThe abstract operation InstanceofOperator(O, C) implements the generic algorithm for determining if an object O inherits from the inheritance path defined by constructor C. This abstract operation performs the following steps:
NOTE Steps 5 and 6 provide compatibility with previous editions of ECMAScript that did not use
a @@hasInstance method to define the instanceof
operator semantics. If a function object does not define or
inherit @@hasInstance it uses the default instanceof
semantics.
NOTE The result of evaluating an equality operator is always of type Boolean, reflecting whether the relationship named by the operator holds between its two operands.
==
RelationalExpression[?In, ?Yield]!=
RelationalExpression[?In, ?Yield]===
RelationalExpression[?In, ?Yield]!==
RelationalExpression[?In, ?Yield]See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
==
RelationalExpression!=
RelationalExpression===
RelationalExpression!==
RelationalExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
==
RelationalExpression!=
RelationalExpression===
RelationalExpression!==
RelationalExpression==
RelationalExpression!=
RelationalExpression===
RelationalExpression!==
RelationalExpressionNOTE 1 Given the above definition of equality:
"" + a == "" + b
.+a == +b
.!a == !b
.NOTE 2 The equality operators maintain the following invariants:
A
!=
B
is equivalent to !(A
==
B)
.A
==
B
is equivalent to B
==
A
, except
in the order of evaluation of A
and B
.NOTE 3 The equality operator is not always transitive. For example, there might be two distinct
String objects, each representing the same String value; each String object would be considered equal to the String value
by the ==
operator, but the two String objects would not be equal to each other. For example:
new String("a") == "a"
and "a" == new String("a
") are both true.new String("a") == new String("a")
is false.NOTE 4 Comparison of Strings uses a simple equality test on sequences of code unit values. There is no attempt to use the more complex, semantically oriented definitions of character or string equality and collating order defined in the Unicode specification. Therefore Strings values that are canonically equal according to the Unicode standard could test as unequal. In effect this algorithm assumes that both Strings are already in normalized form.
&
EqualityExpression[?In, ?Yield]^
BitwiseANDExpression[?In, ?Yield]|
BitwiseXORExpression[?In, ?Yield]See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.12.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
BitwiseANDExpression : BitwiseANDExpression &
EqualityExpression
BitwiseXORExpression : BitwiseXORExpression ^
BitwiseANDExpression
BitwiseORExpression : BitwiseORExpression |
BitwiseXORExpression
See also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.12.2, 12.13.2, 12.14.3, 12.15.2.
BitwiseANDExpression : BitwiseANDExpression &
EqualityExpression
BitwiseXORExpression : BitwiseXORExpression ^
BitwiseANDExpression
BitwiseORExpression : BitwiseORExpression |
BitwiseXORExpression
The production A : A @ B, where @ is one of the bitwise operators in the productions above, is evaluated as follows:
&&
BitwiseORExpression[?In, ?Yield]||
LogicalANDExpression[?In, ?Yield]NOTE The value produced by a &&
or ||
operator is not
necessarily of type Boolean. The value produced will always be the value of one of the two operand expressions.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.13.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
LogicalANDExpression : LogicalANDExpression &&
BitwiseORExpression
LogicalORExpression : LogicalORExpression ||
LogicalANDExpression
See also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.13.2, 12.14.3, 12.15.2.
LogicalANDExpression : LogicalANDExpression &&
BitwiseORExpression
LogicalORExpression : LogicalORExpression ||
LogicalANDExpression
&&
BitwiseORExpression||
LogicalANDExpression? : )
?
AssignmentExpression[In, ?Yield] :
AssignmentExpression[?In, ?Yield]NOTE The grammar for a ConditionalExpression in ECMAScript is slightly different from that in C and Java, which each allow the second subexpression to be an Expression but restrict the third expression to be a ConditionalExpression. The motivation for this difference in ECMAScript is to allow an assignment expression to be governed by either arm of a conditional and to eliminate the confusing and fairly useless case of a comma expression as the centre expression.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.14.2, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
?
AssignmentExpression :
AssignmentExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.14.3, 12.15.2.
?
AssignmentExpression :
AssignmentExpression?
AssignmentExpression :
AssignmentExpression=
AssignmentExpression[?In, ?Yield]*=
/=
%=
+=
-=
<<=
>>=
>>>=
&=
^=
|=
=
AssignmentExpressionIt is a Syntax Error if LeftHandSideExpression is either an ObjectLiteral or an ArrayLiteral and the lexical token sequence matched by LeftHandSideExpression cannot be parsed with no tokens left over using AssignmentPattern as the goal symbol.
It is an early Reference Error if LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral and IsValidSimpleAssignmentTarget of LeftHandSideExpression is false.
It is an early Reference Error if IsValidSimpleAssignmentTarget of LeftHandSideExpression is false.
See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.15.1, 14.1.11, 14.4.9, 14.5.8.
=
AssignmentExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.15.2.
=
AssignmentExpressionAssignmentExpression[In, Yield] : LeftHandSideExpression[?Yield] =
AssignmentExpression[?In, ?Yield]
"name"
).@
where AssignmentOperator is @=
NOTE When an assignment occurs within strict mode code, it is an runtime error if lref in step 1.f.of the first algorithm or step 9 of the second algorithm it is an unresolvable reference. If it is, a ReferenceError exception is thrown. The LeftHandSide also may not be a reference to a data property with the attribute value {[[Writable]]:false}, to an accessor property with the attribute value {[[Set]]:undefined}, nor to a non-existent property of an object for which the IsExtensible predicate returns the value false. In these cases a TypeError exception is thrown.
In certain circumstances when processing the production AssignmentExpression
: LeftHandSideExpression =
AssignmentExpression the following grammar is used to refine the interpretation of LeftHandSideExpression.
{
}
{
AssignmentPropertyList[?Yield] }
{
AssignmentPropertyList[?Yield] ,
}
[
Elisionopt AssignmentRestElement[?Yield]opt ]
[
AssignmentElementList[?Yield] ]
[
AssignmentElementList[?Yield] ,
Elisionopt AssignmentRestElement[?Yield]opt ]
,
AssignmentProperty[?Yield],
AssignmentElisionElement[?Yield]:
AssignmentElement[?Yield]...
DestructuringAssignmentTarget[?Yield]It is a Syntax Error if IsValidSimpleAssignmentTarget of IdentifierReference is false.
It is a Syntax Error if LeftHandSideExpression is either an ObjectLiteral or an ArrayLiteral and if the lexical token sequence matched by LeftHandSideExpression cannot be parsed with no tokens left over using AssignmentPattern as the goal symbol.
It is a Syntax Error if LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral and IsValidSimpleAssignmentTarget(LeftHandSideExpression) is false.
with parameter value
{
}
{
AssignmentPropertyList }
{
AssignmentPropertyList ,
}
[
]
[
Elision ]
[
Elisionopt AssignmentRestElement ]
[
AssignmentElementList ]
[
AssignmentElementList ,
Elisionopt AssignmentRestElementopt ]
,
AssignmentProperty"name"
).:
AssignmentElementwith parameters iteratorRecord
,
AssignmentElisionElement,
,
AssignmentElement[Yield] : DestructuringAssignmentTarget Initializeropt
"name"
).NOTE Left to right evaluation order is maintained by evaluating a DestructuringAssignmentTarget that is not a destructuring pattern prior to accessing the iterator or evaluating the Initializer.
AssignmentRestElement[Yield] : ...
DestructuringAssignmentTarget
with parameters value and propertyName
AssignmentElement[Yield] : DestructuringAssignmentTarget Initializeropt
"name"
).,
),
AssignmentExpression[?In, ?Yield]See also: 12.2.1.3, 12.2.10.2, 12.3.1.2, 12.4.2, 12.5.2, 12.6.1, 12.7.1, 12.8.1, 12.9.1, 12.10.1, 12.11.1, 12.12.1, 12.13.1, 12.14.2, 14.1.11, 14.4.9, 14.5.8.
,
AssignmentExpressionSee also: 12.1.3, 12.2.1.5, 12.2.10.3, 12.3.1.5, 12.4.3, 12.5.3, 12.6.2, 12.7.2, 12.8.2, 12.9.2, 12.10.2, 12.11.2, 12.12.2, 12.13.2, 12.14.3.
,
AssignmentExpression,
AssignmentExpressionNOTE GetValue must be called even though its value is not used because it may have observable side-effects.