diff --git a/spec.html b/spec.html index 699ef5e721..a19874603b 100644 --- a/spec.html +++ b/spec.html @@ -55,14 +55,14 @@ background: #fff; } -
+
   title: ECMAScript® 2020 Language Specification
   shortname: ECMA-262
   status: draft
   location: https://tc39.es/ecma262/
 
-

-
+

+

Contributing to this Specification

This specification is developed on GitHub with the help of the ECMAScript community. There are a number of ways to contribute to the development of this specification:

    @@ -500,7 +500,7 @@

    The Syntactic Grammar

    In certain cases, in order to avoid ambiguities, the syntactic grammar uses generalized productions that permit token sequences that do not form a valid ECMAScript |Script| or |Module|. For example, this technique is used for object literals and object destructuring patterns. In such cases a more restrictive supplemental grammar is provided that further restricts the acceptable token sequences. Typically, an early error rule will then define an error condition if "_P_ is not covering an _N_", where _P_ is a Parse Node (an instance of the generalized production) and _N_ is a nonterminal from the supplemental grammar. Here, the sequence of tokens originally matched by _P_ is parsed again using _N_ as the goal symbol. (If _N_ takes grammatical parameters, then they are set to the same values used when _P_ was originally parsed.) An error occurs if the sequence of tokens cannot be parsed as a single instance of _N_, with no tokens left over. Subsequently, algorithms access the result of the parse using a phrase of the form "the _N_ that is covered by _P_". This will always be a Parse Node (an instance of _N_, unique for a given _P_), since any parsing failure would have been detected by an early error rule.

    - +

    Grammar Notation

    Terminal symbols are shown in `fixed width` font, both in the productions of the grammars and throughout this specification whenever the text directly refers to such a terminal symbol. These are to appear in a script exactly as written. All terminal symbol code points specified in this way are to be understood as the appropriate Unicode code points from the Basic Latin range, as opposed to any similar-looking code points from other Unicode ranges. A code point in a terminal symbol cannot be expressed by a `\\` |UnicodeEscapeSequence|.

    Nonterminal symbols are shown in italic type. The definition of a nonterminal (also called a “production”) is introduced by the name of the nonterminal being defined followed by one or more colons. (The number of colons indicates to which grammar the production belongs.) One or more alternative right-hand sides for the nonterminal then follow on succeeding lines. For example, the syntactic definition:

    @@ -744,12 +744,12 @@

    Algorithm Conventions

    Algorithm steps may declare named aliases for any value using the form “Let _x_ be _someValue_”. These aliases are reference-like in that both _x_ and _someValue_ refer to the same underlying data and modifications to either are visible to both. Algorithm steps that want to avoid this reference-like behaviour should explicitly make a copy of the right-hand side: “Let _x_ be a copy of _someValue_” creates a shallow copy of _someValue_.

    Once declared, an alias may be referenced in any subsequent steps and must not be referenced from steps prior to the alias's declaration. Aliases may be modified using the form “Set _x_ to _someOtherValue_”.

    - +

    Abstract Operations

    In order to facilitate their use in multiple parts of this specification, some algorithms, called abstract operations, are named and written in parameterized functional form so that they may be referenced by name from within other algorithms. Abstract operations are typically referenced using a functional application style such as OperationName(_arg1_, _arg2_). Some abstract operations are treated as polymorphically dispatched methods of class-like specification abstractions. Such method-like abstract operations are typically referenced using a method application style such as _someValue_.OperationName(_arg1_, _arg2_).

    - +

    Syntax-Directed Operations

    A syntax-directed operation is a named operation whose definition consists of algorithms, each of which is associated with one or more productions from one of the ECMAScript grammars. A production that has multiple alternative definitions will typically have a distinct algorithm for each alternative. When an algorithm is associated with a grammar production, it may reference the terminal and nonterminal symbols of the production alternative as if they were parameters of the algorithm. When used in this manner, nonterminal symbols refer to the actual alternative definition that is matched when parsing the source text. The source text matched by a grammar production is the portion of the source text that starts at the beginning of the first terminal that participated in the match and ends at the end of the last terminal that participated in the match.

    When an algorithm is associated with a production alternative, the alternative is typically shown without any “[ ]” grammar annotations. Such annotations should only affect the syntactic recognition of the alternative and have no effect on the associated semantics for the alternative.

    @@ -894,7 +894,7 @@

    Static Semantics

    The above definition is explicitly over-ridden for specific productions.

    A special kind of static semantic rule is an Early Error Rule. Early error rules define early error conditions (see clause ) that are associated with specific grammar productions. Evaluation of most early error rules are not explicitly invoked within the algorithms of this specification. A conforming implementation must, prior to the first evaluation of a |Script| or |Module|, validate all of the early error rules of the productions used to parse that |Script| or |Module|. If any of the early error rules are violated the |Script| or |Module| is invalid and cannot be evaluated.

    - +

    Mathematical Operations

    This specification makes reference to two kinds of numeric values:

      @@ -12108,7 +12108,7 @@

      Static Semantics: TV and TRV

      Automatic Semicolon Insertion

      Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

      - +

      Rules of Automatic Semicolon Insertion

      In the following rules, “token” means the actual recognized lexical token determined using the current lexical goal symbol as described in clause .

      There are three basic rules of semicolon insertion:

      @@ -41592,163 +41592,163 @@

      Grammar Summary

      Lexical Grammar

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

      Expressions

      - - - - - - - -

      When processing an instance of the production the interpretation of |CoverParenthesizedExpressionAndArrowParameterList| is refined using the following grammar:

      - + + + + + + + +

      When processing an instance of the production the interpretation of |CoverParenthesizedExpressionAndArrowParameterList| is refined using the following grammar:

      +

       

      - - - - - - - - - - - - - - - - - - - - - - - - -

      When processing an instance of the production the interpretation of |CoverCallExpressionAndAsyncArrowHead| is refined using the following grammar:

      - + + + + + + + + + + + + + + + + + + + + + + + + +

      When processing an instance of the production the interpretation of |CoverCallExpressionAndAsyncArrowHead| is refined using the following grammar:

      +

       

      - - - - - - - - - - - - - - - - - - - - - - - - - - -

      In certain circumstances when processing an instance of the production the following grammar is used to refine the interpretation of |LeftHandSideExpression|:

      + + + + + + + + + + + + + + + + + + + + + + + + + + +

      In certain circumstances when processing an instance of the production the following grammar is used to refine the interpretation of |LeftHandSideExpression|:

      @@ -41761,215 +41761,215 @@

      Expressions

       

      - - + +

      Statements

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

      Functions and Classes

      - - - - - - - - - - - - - -

      When the production is recognized the following grammar is used to refine the interpretation of |CoverParenthesizedExpressionAndArrowParameterList|:

      - + + + + + + + + + + + + + +

      When the production is recognized the following grammar is used to refine the interpretation of |CoverParenthesizedExpressionAndArrowParameterList|:

      +

       

      - - -

      When the production is recognized the following grammar is used to refine the interpretation of |CoverParenthesizedExpressionAndArrowParameterList|:

      - + + +

      When the production is recognized the following grammar is used to refine the interpretation of |CoverParenthesizedExpressionAndArrowParameterList|:

      +

       

      - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +

      Scripts and Modules

      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +

      Number Conversions

      - - - - - - - - - - - - - + + + + + + + + + + + + +

      All grammar symbols not explicitly defined by the |StringNumericLiteral| grammar have the definitions used in the Lexical Grammar for numeric literals.

      Universal Resource Identifier Character Classes

      - - - - - - - - + + + + + + + +

      Regular Expressions

      - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +

      Each `\\u` |TrailSurrogate| for which the choice of associated `u` |LeadSurrogate| is ambiguous shall be associated with the nearest possible `u` |LeadSurrogate| that would otherwise have no corresponding `\\u` |TrailSurrogate|.

       

      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      - +

      Additional ECMAScript Features for Web Browsers

      The ECMAScript language syntax and semantics defined in this annex are required when the ECMAScript host is a web browser. The content of this annex is normative but optional if the ECMAScript host is not a web browser.