7 Lexical Conventions # Ⓣ Ⓔ ① Ⓐ — Annotated ES5 (original) (raw)

Annotated ECMAScript 5.1

‟Ex igne vita”

← 6 Source Text –TOC –8 Types →

  1. 7 Lexical Conventions Ⓔ ① Ⓐ
    1. 7.1 Unicode Format-Control Characters Ⓔ ① Ⓐ
    2. 7.2 White Space Ⓔ ① Ⓐ
    3. 7.3 Line Terminators Ⓔ ① Ⓐ
    4. 7.4 Comments Ⓔ ① Ⓐ
    5. 7.5 Tokens Ⓔ ① Ⓐ
    6. 7.6 Identifier Names and Identifiers Ⓔ ① Ⓐ
      1. 7.6.1 Reserved Words Ⓔ ① Ⓐ
        1. 7.6.1.1 Keywords Ⓔ ① Ⓐ
        2. 7.6.1.2 Future Reserved Words Ⓔ ① Ⓐ
    7. 7.7 Punctuators Ⓔ ① Ⓐ
    8. 7.8 Literals Ⓔ ① Ⓐ
      1. 7.8.1 Null Literals Ⓔ ① Ⓐ
      2. 7.8.2 Boolean Literals Ⓔ ① Ⓐ
      3. 7.8.3 Numeric Literals Ⓔ ① Ⓐ
      4. 7.8.4 String Literals Ⓔ ① Ⓐ
      5. 7.8.5 Regular Expression Literals Ⓔ ① Ⓐ
    9. 7.9 Automatic Semicolon Insertion Ⓔ ① Ⓐ
      1. 7.9.1 Rules of Automatic Semicolon Insertion Ⓔ ① Ⓐ
      2. 7.9.2 Examples of Automatic Semicolon Insertion Ⓔ ① Ⓐ

The source text of an ECMAScript program is first converted into a sequence of input elements, which are tokens, line terminators, comments, or white space. The source text is scanned from left to right, repeatedly taking the longest possible sequence of characters as the next input element.

There are two goal symbols for the lexical grammar. The InputElementDiv symbol is used in those syntactic grammar contexts where a leading division (**/**) or division-assignment (**/=**) operator is permitted. The InputElementRegExp symbol is used in other syntactic grammar contexts.

NOTE There are no syntactic grammar contexts where both a leading division or division-assignment, and a leading RegularExpressionLiteral are permitted. This is not affected by semicolon insertion (see7.9); in examples such as the following:

**a = b** **/hi/g.exec(c).map(d);**

where the first non-whitespace, non-comment character after a LineTerminator is slash (**/**) and the syntactic context allows division or division-assignment, no semicolon is inserted at the_LineTerminator_. That is, the above example is interpreted in the same way as:

**a = b / hi / g.** **exec** **(c).map(d);**

Syntax

InputElementDiv ::

WhiteSpace LineTerminator Comment Token DivPunctuator

InputElementRegExp ::

WhiteSpace LineTerminator Comment Token RegularExpressionLiteral

7.1 Unicode Format-Control Characters # Ⓣ Ⓔ ① Ⓐ

The Unicode format-control characters (i.e., the characters in category “Cf” in the Unicode Character Database such as left-to-right mark or right-to-left mark) are control codes used to control the formatting of a range of text in the absence of higher-level protocols for this (such as mark-up languages).

It is useful to allow format-control characters in source text to facilitate editing and display. All format control characters may be used within comments, and within string literals and regular expression literals.

and are format-control characters that are used to make necessary distinctions when forming words or phrases in certain languages. In ECMAScript source text, and may also be used in an identifier after the first character.

is a format-control character used primarily at the start of a text to mark it as Unicode and to allow detection of the text's encoding and byte order. characters intended for this purpose can sometimes also appear after the start of a text, for example as a result of concatenating files. characters are treated as white space characters (see7.2).

The special treatment of certain format-control characters outside of comments, string literals, and regular expression literals is summarized in Table 1.

Table 1 — Format-Control Character Usage

| | | | | | | ----------- | --------------------- | ------ | ---------------- | | \u200C | Zero width non-joiner | | IdentifierPart | | \u200D | Zero width joiner | | IdentifierPart | | \uFEFF | Byte Order Mark | | Whitespace |

7.2 White Space # Ⓣ Ⓔ ① Ⓐ

White space characters are used to improve source text readability and to separate tokens (indivisible lexical units) from each other, but are otherwise insignificant. White space characters may occur between any two tokens and at the start or end of input. White space characters may also occur within a StringLiteral or a RegularExpressionLiteral (where they are considered significant characters forming part of the literal value) or within a Comment, but cannot appear within any other kind of token.

The ECMAScript white space characters are listed in Table 2.

Table 2 — Whitespace Characters

| | | | | | -------------------------------- | ---------------------------------------------------- | ------------ | | \u0009 | Tab | | | \u000B | Vertical Tab | | | \u000C | Form Feed | | | \u0020 | Space | | | \u00A0 | No-break space | <#x0a> | | \uFEFF Other category “Zs” | Byte Order Mark Any other Unicode “space separator” | |

ECMAScript implementations must recognize all of the white space characters defined in Unicode 3.0. Later editions of the Unicode Standard may define other white space characters. ECMAScript implementations may recognize white space characters from later editions of the Unicode Standard.

Syntax

WhiteSpace::

<#x0a>

7.3 Line Terminators # Ⓣ Ⓔ ① Ⓐ

Like white space characters, line terminator characters are used to improve source text readability and to separate tokens (indivisible lexical units) from each other. However, unlike white space characters, line terminators have some influence over the behaviour of the syntactic grammar. In general, line terminators may occur between any two tokens, but there are a few places where they are forbidden by the syntactic grammar. Line terminators also affect the process of automatic semicolon insertion (7.9). A line terminator cannot occur within any token except a StringLiteral. Line terminators may only occur within a StringLiteral token as part of a LineContinuation.

A line terminator can occur within a MultiLineComment (7.4) but cannot occur within a SingleLineComment.

Line terminators are included in the set of white space characters that are matched by the **\s** class in regular expressions.

The ECMAScript line terminator characters are listed in Table 3.

Table 3 — Line Terminator Characters

| | | | | | ----------- | ------------------- | ---- | | \u000A | Line Feed | | | \u000D | Carriage Return | | | \u2028 | Line separator | | | \u2029 | Paragraph separator | |

Only the characters in Table 3 are treated as line terminators. Other new line or line breaking characters are treated as white space but not as line terminators. The character sequence is commonly used as a line terminator. It should be considered a single character for the purpose of reporting line numbers.

Syntax

LineTerminator ::

LineTerminatorSequence ::

\[[lookahead∉](x5.html#lookahead-not-in) \]

7.4 Comments # Ⓣ Ⓔ ① Ⓐ

Comments can be either single or multi-line. Multi-line comments cannot nest.

Because a single-line comment can contain any character except a_LineTerminator_ character, and because of the general rule that a token is always as long as possible, a single-line comment always consists of all characters from the **//** marker to the end of the line. However, the LineTerminator at the end of the line is not considered to be part of the single-line comment; it is recognised separately by the lexical grammar and becomes part of the stream of input elements for the syntactic grammar. This point is very important, because it implies that the presence or absence of single-line comments does not affect the process of automatic semicolon insertion (see 7.9).

Comments behave like white space and are discarded except that, if a_MultiLineComment_ contains a line terminator character, then the entire comment is considered to be a LineTerminator for purposes of parsing by the syntactic grammar.

Syntax

Comment ::

MultiLineComment SingleLineComment

MultiLineComment ::

**/*** _MultiLineCommentChars_opt***/**

MultiLineCommentChars ::

_MultiLineNotAsteriskChar MultiLineCommentChars_opt***** _PostAsteriskCommentChars_opt

PostAsteriskCommentChars ::

_MultiLineNotForwardSlashOrAsteriskChar MultiLineCommentChars_opt***** _PostAsteriskCommentChars_opt

MultiLineNotAsteriskChar::

SourceCharacter but not asterisk *****

MultiLineNotForwardSlashOrAsteriskChar ::

SourceCharacterbut not forward-slash **/** orasterisk *****

SingleLineComment ::

**//** _SingleLineCommentChars_opt

SingleLineCommentChars ::

_SingleLineCommentChar SingleLineCommentChars_opt

SingleLineCommentChar ::

SourceCharacterbut not LineTerminator

7.5 Tokens # Ⓣ Ⓔ ① Ⓐ

Syntax

Token ::

IdentifierName Punctuator NumericLiteral StringLiteral

NOTE The_DivPunctuator_ and_RegularExpressionLiteral_ productions define tokens, but are not included in the Token production.

7.6 Identifier Names and Identifiers # Ⓣ Ⓔ ① Ⓐ

Identifier Names are tokens that are interpreted according to the grammar given in the “Identifiers” section of chapter 5 of the Unicode standard, with some small modifications. An Identifier is an IdentifierName that is not a ReservedWord (see 7.6.1). The Unicode identifier grammar is based on both normative and informative character categories specified by the Unicode Standard. The characters in the specified categories in version 3.0 of the Unicode standard must be treated as in those categories by all conforming ECMAScript implementations.

This standard specifies specific character additions: The dollar sign (**$**) and the underscore (**_**) are permitted anywhere in an IdentifierName.

Unicode escape sequences are also permitted in an IdentifierName, where they contribute a single character to the IdentifierName, as computed by the CV of the UnicodeEscapeSequence (see 7.8.4). The **\** preceding the UnicodeEscapeSequence does not contribute a character to the IdentifierName. A UnicodeEscapeSequence cannot be used to put a character into an IdentifierName that would otherwise be illegal. In other words, if a **\** UnicodeEscapeSequence sequence were replaced by its UnicodeEscapeSequence's CV, the result must still be a valid IdentifierName that has the exact same sequence of characters as the original IdentifierName. All interpretations of identifiers within this specification are based upon their actual characters regardless of whether or not an escape sequence was used to contribute any particular characters.

Two_IdentifierName_ that are canonically equivalent according to the Unicode standard are not equal unless they are represented by the exact same sequence of code units (in other words, conforming ECMAScript implementations are only required to do bitwise comparison on IdentifierName values). The intent is that the incoming source text has been converted to normalised form C before it reaches the compiler.

ECMAScript implementations may recognize identifier characters defined in later editions of the Unicode Standard. If portability is a concern, programmers should only employ identifier characters defined in Unicode 3.0.

Syntax

Identifier ::

IdentifierName but not ReservedWord

IdentifierName::

IdentifierStart IdentifierName IdentifierPart

IdentifierStart ::

UnicodeLetter **$** **_** **\** UnicodeEscapeSequence

IdentifierPart ::

IdentifierStart UnicodeCombiningMark UnicodeDigit UnicodeConnectorPunctuation

UnicodeLetter

any character in the Unicode categories “Uppercase letter (Lu)”, “Lowercase letter (Ll)”, “Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”, or “Letter number (Nl)”.

UnicodeCombiningMark

any character in the Unicode categories “Non-spacing mark (Mn)” or “Combining spacing mark (Mc)”

UnicodeDigit

any character in the Unicode category “Decimal number (Nd)”

UnicodeConnectorPunctuation

any character in the Unicode category “Connector punctuation (Pc)”

UnicodeEscapeSequence

see7.8.4.

7.6.1 Reserved Words # Ⓣ Ⓔ ① Ⓐ

A reserved word is an IdentifierName that cannot be used as an Identifier.

Syntax

ReservedWord::

Keyword FutureReservedWord NullLiteral BooleanLiteral

7.6.1.1 Keywords # Ⓣ Ⓔ ① Ⓐ

The following tokens are ECMAScript keywords and may not be used as_Identifiers_ in ECMAScript programs.

Syntax

Keyword :: one of

break do instanceof typeof
case else new var
catch finally return void
continue for switch while
debugger function this with
default if throw
delete in try
7.6.1.2 Future Reserved Words # Ⓣ Ⓔ ① Ⓐ

The following words are used as keywords in proposed extensions and are therefore reserved to allow for the possibility of future adoption of those extensions.

Syntax

FutureReservedWord:: one of

class enum extends super
const export import

The following tokens are also considered to be FutureReservedWords when they occur within strict mode code (see 10.1.1). The occurrence of any of these tokens within strict mode code in any context where the occurrence of a FutureReservedWord would produce an error must also produce an equivalent error:

implements let private public yield
interface package protected static

7.7 Punctuators # Ⓣ Ⓔ ① Ⓐ

Syntax

Punctuator :: one of

{ } ( ) [ ]
. ; , < > <=
>= == != === !==
+ - * % ++ --
<< >> >>> & | ^
! ~ && **| ** ?
= += -= *= %= <<=
>>= >>>= &= |= ^=

DivPunctuator :: one of

| / | /= | | | | | | ----- | ------ | | | | |

7.8 Literals # Ⓣ Ⓔ ① Ⓐ

Syntax

Literal ::

NullLiteral BooleanLiteral NumericLiteral StringLiteral RegularExpressionLiteral

7.8.1 Null Literals # Ⓣ Ⓔ ① Ⓐ

Syntax

NullLiteral ::

**null**

Semantics

The value of the null literal **null** is the sole value of the Null type, namely null.

7.8.2 Boolean Literals # Ⓣ Ⓔ ① Ⓐ

Syntax

BooleanLiteral ::

**true** **false**

Semantics

The value of the Boolean literal **true** is a value of the Boolean type, namely true.

The value of the Boolean literal **false** is a value of the Boolean type, namely false.

7.8.3 Numeric Literals # Ⓣ Ⓔ ① Ⓐ

Syntax

NumericLiteral::

DecimalLiteral HexIntegerLiteral

DecimalLiteral ::

DecimalIntegerLiteral **.** _DecimalDigits_opt _ExponentPart_opt**.** _DecimalDigits ExponentPart_opt
_DecimalIntegerLiteral ExponentPart_opt

DecimalIntegerLiteral::

**0**
_NonZeroDigit DecimalDigits_opt

DecimalDigits ::

DecimalDigit DecimalDigits DecimalDigit

DecimalDigit :: one of

**0 1 2 3 4 5 6 7 8 9**

NonZeroDigit :: one of

**1 2 3 4 5 6 7 8 9**

ExponentPart ::

ExponentIndicator SignedInteger

ExponentIndicator :: one of

**e E**

SignedInteger::

DecimalDigits **+** DecimalDigits **-** DecimalDigits

HexIntegerLiteral ::

**0x** HexDigit **0X** HexDigit HexIntegerLiteral HexDigit

HexDigit :: one of

**0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F**

The source character immediately following a NumericLiteral must not be an IdentifierStart or DecimalDigit.

NOTE For example:

**3in**

is an error and not the two input elements **3** and **in**.

Semantics

A numeric literal stands for a value of the Number type. This value is determined in two steps: first, a mathematical value (MV) is derived from the literal; second, this mathematical value is rounded as described below.

Once the exact MV for a numeric literal has been determined, it is then rounded to a value of the Number type. If the MV is 0, then the rounded value is +0; otherwise, the rounded value must be the Number value for the MV (as specified in 8.5), unless the literal is a DecimalLiteral and the literal has more than 20 significant digits, in which case the Number value may be either the Number value for the MV of a literal produced by replacing each significant digit after the 20th with a **0** digit or the Number value for the MV of a literal produced by replacing each significant digit after the 20th with a **0** digit and then incrementing the literal at the 20th significant digit position. A digit is significant if it is not part of an ExponentPart and

A conforming implementation, when processing strict mode code (see10.1.1), must not extend the syntax of NumericLiteral to include OctalIntegerLiteral as described in B.1.1.

7.8.4 String Literals # Ⓣ Ⓔ ① Ⓐ

A string literal is zero or more characters enclosed in single or double quotes. Each character may be represented by an escape sequence. All characters may appear literally in a string literal except for the closing quote character, backslash, carriage return, line separator, paragraph separator, and line feed. Any character may appear in the form of an escape sequence.

Syntax

StringLiteral ::

**"** _DoubleStringCharacters_opt**"** **'** _SingleStringCharacters_opt**'**

DoubleStringCharacters ::

_DoubleStringCharacter DoubleStringCharacters_opt

SingleStringCharacters ::

_SingleStringCharacter SingleStringCharacters_opt

DoubleStringCharacter ::

SourceCharacter but not double-quote **"** orbackslash **\** orLineTerminator **\** EscapeSequence LineContinuation

SingleStringCharacter ::

SourceCharacter but not single-quote **'** orbackslash **\** orLineTerminator **\** EscapeSequence LineContinuation

LineContinuation ::

**\** LineTerminatorSequence

EscapeSequence ::

CharacterEscapeSequence **0** [lookahead∉ _DecimalDigit_]
HexEscapeSequence UnicodeEscapeSequence

CharacterEscapeSequence ::

SingleEscapeCharacter NonEscapeCharacter

SingleEscapeCharacter :: one of

**' " \ b f n r t v**

NonEscapeCharacter::

SourceCharacterbut not EscapeCharacter orLineTerminator

EscapeCharacter ::

SingleEscapeCharacter DecimalDigit **x** **u**

HexEscapeSequence ::

**x** HexDigit HexDigit

UnicodeEscapeSequence ::

**u** HexDigit HexDigit HexDigit HexDigit

The definitions of the nonterminal HexDigit is given in 7.6. SourceCharacter is defined in clause 6.

Semantics

A string literal stands for a value of the String type. The String value (SV) of the literal is described in terms of character values (CV) contributed by the various parts of the string literal. As part of this process, some characters within the string literal are interpreted as having a mathematical value (MV), as described below or in 7.8.3.

Table 4 — String Single Character Escape Sequences

| | | | | |
| -------- | ----------- | -------------------- | ------ |
| \b | \u0008 | backspace | |
| \t | \u0009 | horizontal tab | |
| \n | \u000A | line feed (new line) | |
| \v | \u000B | vertical tab | |
| \f | \u000C | form feed | |
| \r | \u000D | carriage return | |
| \" | \u0022 | double quote | " |
| \' | \u0027 | single quote | ' |
| \\ | \u005C | backslash | \ |

A conforming implementation, when processing strict mode code (see10.1.1), may not extend the syntax of EscapeSequence to include OctalEscapeSequence as described in B.1.2.

NOTE A line terminator character cannot appear in a string literal, except as part of a LineContinuation to produce the empty character sequence. The correct way to cause a line terminator character to be part of the String value of a string literal is to use an escape sequence such as **\n** or **\u000A**.

7.8.5 Regular Expression Literals # Ⓣ Ⓔ ① Ⓐ

A regular expression literal is an input element that is converted to a RegExp object (see 15.10) each time the literal is evaluated. Two regular expression literals in a program evaluate to regular expression objects that never compare as **===** to each other even if the two literals' contents are identical. A RegExp object may also be created at runtime by **new RegExp** (see 15.10.4) or calling the **RegExp** constructor as a function (15.10.3).

The productions below describe the syntax for a regular expression literal and are used by the input element scanner to find the end of the regular expression literal. The Strings of characters comprising the RegularExpressionBody and the RegularExpressionFlags are passed uninterpreted to the regular expression constructor, which interprets them according to its own, more stringent grammar. An implementation may extend the regular expression constructor's grammar, but it must not extend the RegularExpressionBody and RegularExpressionFlags productions or the productions used by these productions.

Syntax

RegularExpressionLiteral ::

**/** RegularExpressionBody **/** RegularExpressionFlags

RegularExpressionBody::

RegularExpressionFirstChar RegularExpressionChars

RegularExpressionChars ::

[empty]
RegularExpressionChars RegularExpressionChar

RegularExpressionFirstChar ::

RegularExpressionNonTerminator but not ***** or **\** or **/**or **[**
RegularExpressionBackslashSequence RegularExpressionClass

RegularExpressionChar ::

RegularExpressionNonTerminatorbut not **\** or **/**or **[**
RegularExpressionBackslashSequence RegularExpressionClass

RegularExpressionBackslashSequence ::

**\** RegularExpressionNonTerminator

RegularExpressionNonTerminator ::

SourceCharacterbut not LineTerminator

RegularExpressionClass ::

**[** RegularExpressionClassChars **]**

RegularExpressionClassChars``::

[empty]
RegularExpressionClassChars`` RegularExpressionClassChar

RegularExpressionClassChar``::

RegularExpressionNonTerminatorbut not **]** or **\** RegularExpressionBackslashSequence

RegularExpressionFlags::

[empty]
RegularExpressionFlags IdentifierPart

NOTE Regular expression literals may not be empty; instead of representing an empty regular expression literal, the characters **//** start a single-line comment. To specify an empty regular expression, use: **/(?:)/**.

Semantics

A regular expression literal evaluates to a value of the Object type that is an instance of the standard built-in constructor RegExp. This value is determined in two steps: first, the characters comprising the regular expression's RegularExpressionBody and RegularExpressionFlags production expansions are collected uninterpreted into two Strings Pattern and Flags, respectively. Then each time the literal is evaluated, a new object is created as if by the expression **new RegExp(** Pattern, Flags **)** where RegExp is the standard built-in constructor with that name. The newly constructed object becomes the value of the_RegularExpressionLiteral_. If the call to **new RegExp** would generate an error as specified in 15.10.4.1, the error must be treated as an early error (Clause 16).

7.9 Automatic Semicolon Insertion # Ⓣ Ⓔ ① Ⓐ

Certain ECMAScript statements (empty statement, variable statement, expression statement, **do**-**while** statement, **continue** statement, **break** statement, **return** statement, and **throw** statement) must be terminated with semicolons. 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.

7.9.1 Rules of Automatic Semicolon Insertion # Ⓣ Ⓔ ① Ⓐ

There are three basic rules of semicolon insertion:

  1. When, as the program is parsed from left to right, a token (called the_offending token_) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:
    • The offending token is separated from the previous token by at least one LineTerminator.
    • The offending token is **}**.
  2. When, as the program is parsed from left to right, the end of the input stream of tokens is encountered and the parser is unable to parse the input token stream as a single complete ECMAScript Program, then a semicolon is automatically inserted at the end of the input stream.
  3. When, as the program is parsed from left to right, a token is encountered that is allowed by some production of the grammar, but the production is a restricted production and the token would be the first token for a terminal or nonterminal immediately following the annotation “[no LineTerminator here]” within the restricted production (and therefore such a token is called a restricted token), and the restricted token is separated from the previous token by at least one LineTerminator, then a semicolon is automatically inserted before the restricted token.

However, there is an additional overriding condition on the preceding rules: a semicolon is never inserted automatically if the semicolon would then be parsed as an empty statement or if that semicolon would become one of the two semicolons in the header of a **for** statement (see 12.6.3).

NOTE The following are the only restricted productions in the grammar:

PostfixExpression :

LeftHandSideExpression[\[no _LineTerminator_ here\]](x5.html#restricted-production)` **++**` _LeftHandSideExpression_[no LineTerminator here] **--**

ContinueStatement :

**continue** [no LineTerminator here] Identifier**;**

BreakStatement :

**break** [no LineTerminator here] Identifier**;**

ReturnStatement :

**return** [no LineTerminator here] Expression**;**

ThrowStatement:

**throw** [no LineTerminator here] Expression**;**

The practical effect of these restricted productions is as follows:

When a **++** or **--** token is encountered where the parser would treat it as a postfix operator, and at least one LineTerminator occurred between the preceding token and the **++** or **--** token, then a semicolon is automatically inserted before the **++** or **--** token.

When a **continue**,**break**,**return**, or **throw** token is encountered and a LineTerminator is encountered before the next token, a semicolon is automatically inserted after the **continue**,**break**,**return**, or **throw** token.

The resulting practical advice to ECMAScript programmers is:

A postfix **++** or **--** operator should appear on the same line as its operand.

An_Expression_ in a **return** or **throw** statement should start on the same line as the **return** or **throw** token.

A_Identifier_ in a **break** or **continue** statement should be on the same line as the **break** or **continue** token.

7.9.2 Examples of Automatic Semicolon Insertion # Ⓣ Ⓔ ① Ⓐ

The source

**{ 1 2 } 3**

is not a valid sentence in the ECMAScript grammar, even with the automatic semicolon insertion rules. In contrast, the source

**{ 1** **2 } 3**

is also not a valid ECMAScript sentence, but is transformed by automatic semicolon insertion into the following:

**{ 1** **;2 ;} 3;**

which is a valid ECMAScript sentence.

The source

**for (a; b** **)**

is not a valid ECMAScript sentence and is not altered by automatic semicolon insertion because the semicolon is needed for the header of a **for** statement. Automatic semicolon insertion never inserts one of the two semicolons in the header of a **for** statement.

The source

**return** **a + b**

is transformed by automatic semicolon insertion into the following:

**return;** **a + b;**

NOTE The expression **a + b** is not treated as a value to be returned by the **return** statement, because a LineTerminator separates it from the token **return**.

The source

**a = b** **++c**

is transformed by automatic semicolon insertion into the following:

**a = b;** **++c;**

NOTE The token **++** is not treated as a postfix operator applying to the variable **b**, because a LineTerminator occurs between **b** and **++**.

The source

**if (a > b)** **else c = d**

is not a valid ECMAScript sentence and is not altered by automatic semicolon insertion before the **else** token, even though no production of the grammar applies at that point, because an automatically inserted semicolon would then be parsed as an empty statement.

The source

**a = b + c** **(d + e).print()**

is_not_ transformed by automatic semicolon insertion, because the parenthesised expression that begins the second line can be interpreted as an argument list for a function call:

**a = b + c(d + e).print()**

In the circumstance that an assignment statement must begin with a left parenthesis, it is a good idea for the programmer to provide an explicit semicolon at the end of the preceding statement rather than to rely on automatic semicolon insertion.