?um/p1-90`ECMAScript
lexical input elementsの識別が、そのinput elementsを消費しているsyntactic grammar contextに依存する状況がいくつかあります。このため、lexical grammarには複数の
複数のlexical goalsの使用により、automatic semicolon insertionに影響するlexical ambiguitiesが存在しないことが保証されます。例えば、leading divisionまたはdivision-assignmentと、leading
a = b
/hi/g.exec(c).map(d);a = b / hi / g.exec(c).map(d);Unicode format-control characters（すなわち、LEFT-TO-RIGHT MARKやRIGHT-TO-LEFT MARKなど、Unicode Character Databaseのcategory “Cf”にあるcharacters）は、これに対するより高レベルのprotocols（mark-up languagesなど）が存在しない場合に、textの範囲のformattingを制御するために使用されるcontrol codesです。
source text内でformat-control charactersを許可することは、editingおよびdisplayを容易にするために有用です。すべてのformat control charactersは、comments内、およびstring literals、template literals、regular expression literals内で使用できます。
U+FEFF (ZERO WIDTH NO-BREAK SPACE)は、主にtextの開始時に、それがUnicodeであることをmarkし、textのencodingおよびbyte orderの検出を可能にするために使用されるformat-control characterです。この目的のために意図された<ZWNBSP> charactersは、例えばfilesを連結した結果として、textの開始後に現れることもあります。
White space code pointsは、source textのreadabilityを向上させ、tokens（分割できないlexical units）を互いに分離するために使用されますが、それ以外では重要ではありません。White space code pointsは任意の2つのtokensの間、およびinputの開始または終了に出現できます。White space code pointsは、
ECMAScript white space code pointsは
| Code Points | Name | Abbreviation |
|---|---|---|
U+0009
|
CHARACTER TABULATION | <TAB> |
U+000B
|
LINE TABULATION | <VT> |
U+000C
|
FORM FEED (FF) | <FF> |
U+FEFF
|
ZERO WIDTH NO-BREAK SPACE | <ZWNBSP> |
| general category “Space_Separator”内の任意のcode point | <USP> |
U+0020 (SPACE)およびU+00A0 (NO-BREAK SPACE) code pointsは<USP>の一部です。
white space code pointsと同様に、line terminator code pointsはsource textのreadabilityを向上させ、tokens（分割できないlexical units）を互いに分離するために使用されます。しかし、white space code pointsとは異なり、line terminatorsはsyntactic grammarの振る舞いにある程度影響します。一般に、line terminatorsは任意の2つのtokensの間に出現できますが、syntactic grammarによって禁止される場所がいくつかあります。Line terminatorsはautomatic semicolon insertion（
line terminatorは
Line terminatorsは、regular expressions内の\s classによってmatchされるwhite space code pointsのsetに含まれます。
ECMAScript line terminator code pointsは
| Code Point | Unicode Name | Abbreviation |
|---|---|---|
U+000A
|
LINE FEED (LF) | <LF> |
U+000D
|
CARRIAGE RETURN (CR) | <CR> |
U+2028
|
LINE SEPARATOR | <LS> |
U+2029
|
PARAGRAPH SEPARATOR | <PS> |
Commentsはsingle-lineまたはmulti-lineのいずれかです。Multi-line commentsはnestできません。
single-line commentは// markerから行末までのすべてのcode pointsで構成されます。ただし、行末の
Commentsはwhite spaceのように振る舞い破棄されますが、
このsectionのいくつかのproductionsには、section
Hashbang Commentsはlocation-sensitiveであり、他のtypes of commentsと同様に、syntactic grammarのinput elementsのstreamから破棄されます。
この標準は特定のcode point additionsを指定します：U+0024 (DOLLAR SIGN)およびU+005F (LOW LINE)は
nonterminal
nonterminal _をderiveします。
Unicode properties “ID_Start”および“ID_Continue”を持つcode pointsのsetsは、それぞれUnicode properties “Other_ID_Start”および“Other_ID_Continue”を持つcode pointsを含みます。
Unicode escape sequencesは\はどのcode pointsにも寄与しません。\
Unicode Standardに従ってcanonically equivalentである2つの
The
The
keywordはfixed width fontでliteralに現れます。ECMAScriptのkeywordsには、if、while、async、await、その他多数が含まれます。
reserved wordはidentifierとして使用できないifおよびwhileはreserved wordsです。awaitはasync functionsおよびmodulesの内部でのみreservedです。asyncはreservedではありません；制限なくvariable nameまたはstatement labelとして使用できます。
この仕様は、grammatical productionsとawaitおよびyieldを除き、無条件にreservedです。awaitおよびyieldに対する例外は、parameterized syntactic productionsを使用して
Math、window、toString、および_など、常にidentifiersとして許可され、keywordsではないもの；
下に列挙されるawaitおよびyieldを除いた、identifiersとして決して許可されないもの；
awaitおよびyieldという、contextuallyにidentifiersとして許可されるもの；
let、static、implements、interface、package、private、protected、およびpublic；
常にidentifiersとして許可されるが、特定のsyntactic productions内で、as、async、from、get、meta、of、set、およびtarget。
用語conditional keyword、またはcontextual keywordは、最後の3つのcategoriesに属し、したがってあるcontextsではidentifiersとして、別のcontextsではkeywordsとして使用できるkeywordsを指すために使われることがあります。
\
\ els\u{65}と綴ることによって“else”という名前のvariableを宣言することはできません。
enumは現在、この仕様内でkeywordとして使用されていません。これは、将来のlanguage extensionsでkeywordとして使用するために取っておかれたfuture reserved wordです。
同様に、implements、interface、package、private、protected、およびpublicは
例えば：3inはerrorであり、2つのinput elements 3およびinではありません。
numeric literalはNumber typeまたはBigInt typeの値を表します。
The
string literalは、single quotesまたはdouble quotesで囲まれた0個以上のUnicode code pointsです。Unicode code pointsはescape sequenceによって表すこともできます。closing quote code points、U+005C (REVERSE SOLIDUS)、U+000D (CARRIAGE RETURN)、およびU+000A (LINE FEED)を除き、すべてのcode pointsはstring literal内にliteralに現れてよいです。任意のcode pointsはescape sequenceの形式で現れてよいです。String literalsはECMAScript String valuesにevaluateされます。これらのString valuesを生成するとき、Unicode code pointsは
nonterminal
<LF>および<CR>は、空のcode points sequenceを生成するための\nまたは\u000Aなどのescape sequenceを使用することです。
string literalsが、それを囲むcodeを
function invalid() { "\7"; "use strict"; }The
string literalはString typeの値を表します。SVは、string literalのさまざまなpartsへのrecursive applicationを通じて、string literalsに対するString valuesを生成します。このprocessの一部として、string literal内の一部のUnicode code pointsは、以下または
| Escape Sequence | Code Unit Value | Unicode Character Name | Symbol |
|---|---|---|---|
\b
|
0x0008
|
BACKSPACE | <BS> |
\t
|
0x0009
|
CHARACTER TABULATION | <HT> |
\n
|
0x000A
|
LINE FEED (LF) | <LF> |
\v
|
0x000B
|
LINE TABULATION | <VT> |
\f
|
0x000C
|
FORM FEED (FF) | <FF> |
\r
|
0x000D
|
CARRIAGE RETURN (CR) | <CR> |
\"
|
0x0022
|
QUOTATION MARK |
"
|
\'
|
0x0027
|
APOSTROPHE |
'
|
\\
|
0x005C
|
REVERSE SOLIDUS |
\
|
regular expression literalは、literalがevaluateされるたびにRegExp object（===としてcompareされることのないregular expression objectsへevaluateされます。RegExp objectは、runtimeにnew RegExpによって、またはRegExp
以下のproductionsはregular expression literalのsyntaxを記述し、input element scannerがregular expression literalの終端を見つけるために使用されます。
実装は
Regular expression literalsは空であってはなりません；空のregular expression literalを表す代わりに、code unit sequence //はsingle-line commentを開始します。空のregular expressionを指定するには、/(?:)/を使用してください。
The
The
The
The
ほとんどのECMAScript statementsおよびdeclarationsはsemicolonで終了しなければなりません。そのようなsemicolonsはsource text内に常に明示的に現れてよいです。しかし便宜上、そのようなsemicolonsは特定の状況ではsource textから省略されてもよいです。これらの状況は、そのような状況でsemicolonsがsource code token streamに自動的に挿入される、と述べることで説明されます。
次のrulesでは、“token”とは、clause
semicolon insertionには3つの基本rulesがあります：
source textが左から右へparseされるとき、grammarのどのproductionによっても許可されないtoken（offending tokenと呼ばれる）に遭遇した場合、次の条件の1つ以上がtrueであれば、そのoffending tokenの前にsemicolonが自動的に挿入されます：
}である。
)であり、挿入されたsemicolonがdo-while statement（ただし、上記rulesには追加のoverriding conditionがあります：semicolonがempty statementとしてparseされることになる場合、またはそのsemicolonがfor statement（
grammar内のrestricted productionsは次のものだけです：
これらのrestricted productionsの実際上の効果は次のとおりです：
++ または -- トークンに遭遇し、直前のトークンと ++ または -- トークンの間に少なくとも1つの ++ または -- トークンの前に自動的に挿入される。
using トークンに遭遇し、using トークンの後に自動的に挿入される。
continue、break、return、throw、または yield トークンに遭遇し、次のトークンの前に continue、break、return、throw、または yield トークンの後に自動的に挿入される。
=> トークンの前の async トークンの後に、function、( トークンの前の async トークンは後続のトークンと同じ式またはクラス要素の一部として扱われない。
async トークンの後に、* トークンの前の 結果として、ECMAScript プログラマに対する実践的な助言は次のとおりである:
++ または -- 演算子は、そのオペランドと同じ行に置かれるべきである。
using 宣言内の using トークンと同じ行で開始するべきである。
return または throw 文内の yield 式内の return、throw、または yield トークンと同じ行で開始するべきである。
break または continue 文内の break または continue トークンと同じ行に置かれるべきである。
=> は、同じ行に置かれるべきである。
async トークンは、直後に続くトークンと同じ行に置かれるべきである。
source
{ 1 2 } 3は、automatic semicolon insertion rulesを用いても、ECMAScript grammarにおけるvalid sentenceではありません。対照的に、source
{ 1
2 } 3もvalidなECMAScript sentenceではありませんが、automatic semicolon insertionによって次のように変換されます：
{ 1
;2 ;} 3;これはvalidなECMAScript sentenceです。
source
for (a; b
)はvalidなECMAScript sentenceではなく、automatic semicolon insertionによって変更されません。なぜなら、semicolonはfor statementのheaderに必要だからです。Automatic semicolon insertionは、for statementのheader内の2つのsemicolonsの1つを決して挿入しません。
source
return
a + bはautomatic semicolon insertionによって次のように変換されます：
return;
a + b;a + bをtoken returnから分離しているため、expression a + bはreturn statementによって返される値として扱われません。
source
a = b
++cはautomatic semicolon insertionによって次のように変換されます：
a = b;
++c;++ tokenは、variable bに適用されるpostfix operatorとして扱われません。なぜなら、bと++の間に
source
if (a > b)
else c = dはvalidなECMAScript sentenceではなく、その時点でgrammarのどのproductionも適用されないにもかかわらず、else tokenの前にautomatic semicolon insertionによって変更されません。なぜなら、自動的に挿入されたsemicolonはempty statementとしてparseされることになるからです。
source
a = b + c
(d + e).print()はautomatic semicolon insertionによって変換されません。なぜなら、2行目を開始するparenthesized expressionはfunction callのargument listとして解釈できるからです：
a = b + c(d + e).print()assignment statementがleft parenthesisで開始しなければならない状況では、programmerはautomatic semicolon insertionに頼るのではなく、preceding statementの終端に明示的なsemicolonを提供することがよい考えです。
ECMAScript programsは、automatic semicolon insertionに頼ることで、非常に少ないsemicolonsのstyleで書くことができます。上で説明したように、semicolonsはすべてのnewlineで挿入されるわけではなく、automatic semicolon insertionはline terminatorsをまたいだ複数のtokensに依存する場合があります。
新しいsyntactic featuresがECMAScriptに追加されるにつれて、その前でautomatic semicolon insertionに頼っている行がparseされるときにgrammar productionsを変更させる追加grammar productionsが追加される可能性があります。
このsectionの目的では、automatic semicolon insertionのcaseは、その前にあるsource textに応じてsemicolonが挿入される場合もされない場合もある場所であるなら、interestingとみなされます。このsectionの残りでは、このversion of ECMAScriptにおけるautomatic semicolon insertionのいくつかのinteresting casesを説明します。
(）。semicolonがない場合、2つの行は一緒に[）。semicolonがない場合、2つの行は`）。semicolonがない場合、2つの行は、previous expressionを+または-。semicolonがない場合、2つの行は対応するbinary operatorの使用として解釈されます。/ ECMAScriptには、“[no
このsectionの残りでは、このversion of ECMAScriptで“[no