ECMAScript® 2021 Language Specification

Draft ECMA-262 / February 25, 2021

B.3 Other Additional Features

B.3.1 __proto__ Property Names in Object Initializers

The following Early Error rule is added to those in 13.2.6.1. This rule is not applied under any of the following circumstances:

ObjectLiteral : { PropertyDefinitionList } { PropertyDefinitionList , } Note

The List returned by PropertyNameList does not include string literal property names defined as using a ComputedPropertyName.

In 13.2.6.5 the PropertyDefinitionEvaluation algorithm for the production
PropertyDefinition : PropertyName : AssignmentExpression
is replaced with the following definition:

PropertyDefinition : PropertyName : AssignmentExpression
  1. Let propKey be the result of evaluating PropertyName.
  2. ReturnIfAbrupt(propKey).
  3. If propKey is the String value "__proto__" and if IsComputedPropertyKey(PropertyName) is false, then
    1. Let isProtoSetter be true.
  4. Else,
    1. Let isProtoSetter be false.
  5. If IsAnonymousFunctionDefinition(AssignmentExpression) is true and isProtoSetter is false, then
    1. Let propValue be ? NamedEvaluation of AssignmentExpression with argument propKey.
  6. Else,
    1. Let exprValueRef be the result of evaluating AssignmentExpression.
    2. Let propValue be ? GetValue(exprValueRef).
  7. If isProtoSetter is true, then
    1. If Type(propValue) is either Object or Null, then
      1. Return object.[[SetPrototypeOf]](propValue).
    2. Return NormalCompletion(empty).
  8. Assert: enumerable is true.
  9. Assert: object is an ordinary, extensible object with no non-configurable properties.
  10. Return ! CreateDataPropertyOrThrow(object, propKey, propValue).

B.3.2 Labelled Function Declarations

Prior to ECMAScript 2015, the specification of LabelledStatement did not allow for the association of a statement label with a FunctionDeclaration. However, a labelled FunctionDeclaration was an allowable extension for non-strict code and most browser-hosted ECMAScript implementations supported that extension. In ECMAScript 2015 and later, the grammar production for LabelledStatement permits use of FunctionDeclaration as a LabelledItem but 14.13.1 includes an Early Error rule that produces a Syntax Error if that occurs. That rule is modified with the addition of the highlighted text:

LabelledItem : FunctionDeclaration
  • It is a Syntax Error if any strict mode source code matches this rule.
Note

The early error rules for WithStatement, IfStatement, and IterationStatement prevent these statements from containing a labelled FunctionDeclaration in non-strict code.

B.3.3 Block-Level Function Declarations Web Legacy Compatibility Semantics

Prior to ECMAScript 2015, the ECMAScript specification did not define the occurrence of a FunctionDeclaration as an element of a Block statement's StatementList. However, support for that form of FunctionDeclaration was an allowable extension and most browser-hosted ECMAScript implementations permitted them. Unfortunately, the semantics of such declarations differ among those implementations. Because of these semantic differences, existing web ECMAScript code that uses Block level function declarations is only portable among browser implementation if the usage only depends upon the semantic intersection of all of the browser implementations for such declarations. The following are the use cases that fall within that intersection semantics:

  1. A function is declared and only referenced within a single block

    • One or more FunctionDeclarations whose BindingIdentifier is the name f occur within the function code of an enclosing function g and that declaration is nested within a Block.
    • No other declaration of f that is not a var declaration occurs within the function code of g
    • All occurrences of f as an IdentifierReference are within the StatementList of the Block containing the declaration of f.

  2. A function is declared and possibly used within a single Block but also referenced by an inner function definition that is not contained within that same Block.

    • One or more FunctionDeclarations whose BindingIdentifier is the name f occur within the function code of an enclosing function g and that declaration is nested within a Block.
    • No other declaration of f that is not a var declaration occurs within the function code of g
    • There may be occurrences of f as an IdentifierReference within the StatementList of the Block containing the declaration of f.
    • There is at least one occurrence of f as an IdentifierReference within another function h that is nested within g and no other declaration of f shadows the references to f from within h.
    • All invocations of h occur after the declaration of f has been evaluated.

  3. A function is declared and possibly used within a single block but also referenced within subsequent blocks.

    • One or more FunctionDeclaration whose BindingIdentifier is the name f occur within the function code of an enclosing function g and that declaration is nested within a Block.
    • No other declaration of f that is not a var declaration occurs within the function code of g
    • There may be occurrences of f as an IdentifierReference within the StatementList of the Block containing the declaration of f.
    • There is at least one occurrence of f as an IdentifierReference within the function code of g that lexically follows the Block containing the declaration of f.

The first use case is interoperable with the semantics of Block level function declarations provided by ECMAScript 2015. Any pre-existing ECMAScript code that employs that use case will operate using the Block level function declarations semantics defined by clauses 10, 14, and 15.

ECMAScript 2015 interoperability for the second and third use cases requires the following extensions to the clause 10, clause 15, clause 19.2.1 and clause 16.1.7 semantics.

If an ECMAScript implementation has a mechanism for reporting diagnostic warning messages, a warning should be produced when code contains a FunctionDeclaration for which these compatibility semantics are applied and introduce observable differences from non-compatibility semantics. For example, if a var binding is not introduced because its introduction would create an early error, a warning message should not be produced.

B.3.3.1 Changes to FunctionDeclarationInstantiation

During FunctionDeclarationInstantiation the following steps are performed in place of step 29:

  1. If strict is false, then
    1. For each FunctionDeclaration f that is directly contained in the StatementList of a Block, CaseClause, or DefaultClause, do
      1. Let F be StringValue of the BindingIdentifier of f.
      2. If replacing the FunctionDeclaration f with a VariableStatement that has F as a BindingIdentifier would not produce any Early Errors for func and F is not an element of parameterNames, then
        1. NOTE: A var binding for F is only instantiated here if it is neither a VarDeclaredName, the name of a formal parameter, or another FunctionDeclaration.
        2. If initializedBindings does not contain F and F is not "arguments", then
          1. Perform ! varEnv.CreateMutableBinding(F, false).
          2. Perform varEnv.InitializeBinding(F, undefined).
          3. Append F to instantiatedVarNames.
        3. When the FunctionDeclaration f is evaluated, perform the following steps in place of the FunctionDeclaration Evaluation algorithm provided in 15.2.6:
          1. Let fenv be the running execution context's VariableEnvironment.
          2. Let benv be the running execution context's LexicalEnvironment.
          3. Let fobj be ! benv.GetBindingValue(F, false).
          4. Perform ! fenv.SetMutableBinding(F, fobj, false).
          5. Return NormalCompletion(empty).

B.3.3.2 Changes to GlobalDeclarationInstantiation

During GlobalDeclarationInstantiation the following steps are performed in place of step 13:

  1. Let strict be IsStrict of script.
  2. If strict is false, then
    1. Let declaredFunctionOrVarNames be a new empty List.
    2. Append to declaredFunctionOrVarNames the elements of declaredFunctionNames.
    3. Append to declaredFunctionOrVarNames the elements of declaredVarNames.
    4. For each FunctionDeclaration f that is directly contained in the StatementList of a Block, CaseClause, or DefaultClause Contained within script, do
      1. Let F be StringValue of the BindingIdentifier of f.
      2. If replacing the FunctionDeclaration f with a VariableStatement that has F as a BindingIdentifier would not produce any Early Errors for script, then
        1. If env.HasLexicalDeclaration(F) is false, then
          1. Let fnDefinable be ? env.CanDeclareGlobalVar(F).
          2. If fnDefinable is true, then
            1. NOTE: A var binding for F is only instantiated here if it is neither a VarDeclaredName nor the name of another FunctionDeclaration.
            2. If declaredFunctionOrVarNames does not contain F, then
              1. Perform ? env.CreateGlobalVarBinding(F, false).
              2. Append F to declaredFunctionOrVarNames.
            3. When the FunctionDeclaration f is evaluated, perform the following steps in place of the FunctionDeclaration Evaluation algorithm provided in 15.2.6:
              1. Let genv be the running execution context's VariableEnvironment.
              2. Let benv be the running execution context's LexicalEnvironment.
              3. Let fobj be ! benv.GetBindingValue(F, false).
              4. Perform ? genv.SetMutableBinding(F, fobj, false).
              5. Return NormalCompletion(empty).

B.3.3.3 Changes to EvalDeclarationInstantiation

During EvalDeclarationInstantiation the following steps are performed in place of step 7:

  1. If strict is false, then
    1. Let declaredFunctionOrVarNames be a new empty List.
    2. Append to declaredFunctionOrVarNames the elements of declaredFunctionNames.
    3. Append to declaredFunctionOrVarNames the elements of declaredVarNames.
    4. For each FunctionDeclaration f that is directly contained in the StatementList of a Block, CaseClause, or DefaultClause Contained within body, do
      1. Let F be StringValue of the BindingIdentifier of f.
      2. If replacing the FunctionDeclaration f with a VariableStatement that has F as a BindingIdentifier would not produce any Early Errors for body, then
        1. Let bindingExists be false.
        2. Let thisEnv be lexEnv.
        3. Assert: The following loop will terminate.
        4. Repeat, while thisEnv is not the same as varEnv,
          1. If thisEnv is not an object Environment Record, then
            1. If thisEnv.HasBinding(F) is true, then
              1. Let bindingExists be true.
          2. Set thisEnv to thisEnv.[[OuterEnv]].
        5. If bindingExists is false and varEnv is a global Environment Record, then
          1. If varEnv.HasLexicalDeclaration(F) is false, then
            1. Let fnDefinable be ? varEnv.CanDeclareGlobalVar(F).
          2. Else,
            1. Let fnDefinable be false.
        6. Else,
          1. Let fnDefinable be true.
        7. If bindingExists is false and fnDefinable is true, then
          1. If declaredFunctionOrVarNames does not contain F, then
            1. If varEnv is a global Environment Record, then
              1. Perform ? varEnv.CreateGlobalVarBinding(F, true).
            2. Else,
              1. Let bindingExists be varEnv.HasBinding(F).
              2. If bindingExists is false, then
                1. Perform ! varEnv.CreateMutableBinding(F, true).
                2. Perform ! varEnv.InitializeBinding(F, undefined).
            3. Append F to declaredFunctionOrVarNames.
          2. When the FunctionDeclaration f is evaluated, perform the following steps in place of the FunctionDeclaration Evaluation algorithm provided in 15.2.6:
            1. Let genv be the running execution context's VariableEnvironment.
            2. Let benv be the running execution context's LexicalEnvironment.
            3. Let fobj be ! benv.GetBindingValue(F, false).
            4. Perform ? genv.SetMutableBinding(F, fobj, false).
            5. Return NormalCompletion(empty).

B.3.3.4 Changes to Block Static Semantics: Early Errors

The rules for the following production in 14.2.1 are modified with the addition of the highlighted text:

Block : { StatementList }

B.3.3.5 Changes to switch Statement Static Semantics: Early Errors

The rules for the following production in 14.12.1 are modified with the addition of the highlighted text:

SwitchStatement : switch ( Expression ) CaseBlock

B.3.3.6 Changes to BlockDeclarationInstantiation

During BlockDeclarationInstantiation the following steps are performed in place of step 3.a.ii.1:

  1. If env.HasBinding(dn) is false, then
    1. Perform ! env.CreateMutableBinding(dn, false).

During BlockDeclarationInstantiation the following steps are performed in place of step 3.b.iii:

  1. If the binding for fn in env is an uninitialized binding, then
    1. Perform env.InitializeBinding(fn, fo).
  2. Else,
    1. Assert: d is a FunctionDeclaration.
    2. Perform env.SetMutableBinding(fn, fo, false).

B.3.4 FunctionDeclarations in IfStatement Statement Clauses

The following augments the IfStatement production in 14.6:

IfStatement[Yield, Await, Return] : if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default] else Statement[?Yield, ?Await, ?Return] if ( Expression[+In, ?Yield, ?Await] ) Statement[?Yield, ?Await, ?Return] else FunctionDeclaration[?Yield, ?Await, ~Default] if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default] else FunctionDeclaration[?Yield, ?Await, ~Default] if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default] [lookahead ≠ else]

This production only applies when parsing non-strict code. Code matching this production is processed as if each matching occurrence of FunctionDeclaration[?Yield, ?Await, ~Default] was the sole StatementListItem of a BlockStatement occupying that position in the source code. The semantics of such a synthetic BlockStatement includes the web legacy compatibility semantics specified in B.3.3.

B.3.5 VariableStatements in Catch Blocks

The content of subclause 14.15.1 is replaced with the following:

Catch : catch ( CatchParameter ) Block Note

The Block of a Catch clause may contain var declarations that bind a name that is also bound by the CatchParameter. At runtime, such bindings are instantiated in the VariableDeclarationEnvironment. They do not shadow the same-named bindings introduced by the CatchParameter and hence the Initializer for such var declarations will assign to the corresponding catch parameter rather than the var binding.

This modified behaviour also applies to var and function declarations introduced by direct eval calls contained within the Block of a Catch clause. This change is accomplished by modifying the algorithm of 19.2.1.3 as follows:

Step 3.d.i.2.a.i is replaced by:

  1. If thisEnv is not the Environment Record for a Catch clause, throw a SyntaxError exception.

Step 7.d.ii.4.a.i.i is replaced by:

  1. If thisEnv is not the Environment Record for a Catch clause, let bindingExists be true.

B.3.6 Initializers in ForIn Statement Heads

The following augments the ForInOfStatement production in 14.7.5:

ForInOfStatement[Yield, Await, Return] : for ( var BindingIdentifier[?Yield, ?Await] Initializer[~In, ?Yield, ?Await] in Expression[+In, ?Yield, ?Await] ) Statement[?Yield, ?Await, ?Return]

This production only applies when parsing non-strict code.

The static semantics of ContainsDuplicateLabels in 8.2.1 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Return ContainsDuplicateLabels of Statement with argument labelSet.

The static semantics of ContainsUndefinedBreakTarget in 8.2.2 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Return ContainsUndefinedBreakTarget of Statement with argument labelSet.

The static semantics of ContainsUndefinedContinueTarget in 8.2.3 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Return ContainsUndefinedContinueTarget of Statement with arguments iterationSet and « ».

The static semantics of IsDestructuring in 14.7.5.2 are augmented with the following:

BindingIdentifier : Identifier yield await
  1. Return false.

The static semantics of VarDeclaredNames in 8.1.6 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Let names be the BoundNames of BindingIdentifier.
  2. Append to names the elements of the VarDeclaredNames of Statement.
  3. Return names.

The static semantics of VarScopedDeclarations in 8.1.7 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Let declarations be a List whose sole element is BindingIdentifier.
  2. Append to declarations the elements of the VarScopedDeclarations of Statement.
  3. Return declarations.

The runtime semantics of ForInOfLoopEvaluation in 14.7.5.5 are augmented with the following:

ForInOfStatement : for ( var BindingIdentifier Initializer in Expression ) Statement
  1. Let bindingId be StringValue of BindingIdentifier.
  2. Let lhs be ? ResolveBinding(bindingId).
  3. If IsAnonymousFunctionDefinition(Initializer) is true, then
    1. Let value be NamedEvaluation of Initializer with argument bindingId.
  4. Else,
    1. Let rhs be the result of evaluating Initializer.
    2. Let value be ? GetValue(rhs).
  5. Perform ? PutValue(lhs, value).
  6. Let keyResult be ? ForIn/OfHeadEvaluation(« », Expression, enumerate).
  7. Return ? ForIn/OfBodyEvaluation(BindingIdentifier, Statement, keyResult, enumerate, varBinding, labelSet).

B.3.7 The [[IsHTMLDDA]] Internal Slot

An [[IsHTMLDDA]] internal slot may exist on host-defined objects. Objects with an [[IsHTMLDDA]] internal slot behave like undefined in the ToBoolean and Abstract Equality Comparison abstract operations and when used as an operand for the typeof operator.

Note

Objects with an [[IsHTMLDDA]] internal slot are never created by this specification. However, the document.all object in web browsers is a host-defined exotic object with this slot that exists for web compatibility purposes. There are no other known examples of this type of object and implementations should not create any with the exception of document.all.

B.3.7.1 Changes to ToBoolean

The result column in Table 11 for an argument type of Object is replaced with the following algorithm:

  1. If argument has an [[IsHTMLDDA]] internal slot, return false.
  2. Return true.

B.3.7.2 Changes to Abstract Equality Comparison

The following steps replace step 4 of the Abstract Equality Comparison algorithm:

  1. If Type(x) is Object and x has an [[IsHTMLDDA]] internal slot and y is either null or undefined, return true.
  2. If x is either null or undefined and Type(y) is Object and y has an [[IsHTMLDDA]] internal slot, return true.

B.3.7.3 Changes to the typeof Operator

The following table entry is inserted into Table 37 immediately preceeding the entry for "Object (implements [[Call]])":

Table 83: Additional typeof Operator Results
Type of val Result
Object (has an [[IsHTMLDDA]] internal slot) "undefined"