?um/p1-90`
ECMAScript
字句入力要素の識別が、それらの入力要素を消費する構文文
法コンテキストに依存する状況がいくつか存在する。そのた
め、字句文法には複数の目標記号が必要となる。
複数の字句目標を用いることにより、自動セミコロン挿入
に影響を与える字句上の曖昧性が存在しないことが保証され
る。たとえば、先頭の除算または除算代入と、先頭の
a = b
/hi/g.exec(c).map(d);
ここで、
a = b / hi / g.exec(c).map(d);Unicode の書式制御文字（すなわち、Unicode Character Database における “Cf” カテゴリの文 字。たとえば LEFT-TO-RIGHT MARK や RIGHT-TO-LEFT MARK）は、より高水準のプロトコル （markup language など）が存在しない場合に、ある範 囲のテキストの書式を制御するために用いられる制御 code である。
編集や表示を容易にするため、ソーステキストに書式制御文 字を許可することは有用である。すべての書式制御文字は comment の内部、および string literal、template literal、regular expression literal の内部で使 用してよい。
U+FEFF (ZERO WIDTH NO-BREAK SPACE) は、主
にテキストの先頭において、それが Unicode であること
を示し、かつテキストのエンコーディングおよび byte 順
序を検出可能にするために用いられる書式制御文字である。こ
の目的のための <ZWNBSP> 文字は、たとえば file の連
結の結果として、テキストの先頭以外にも現れることがある。
White space code point は、ソーステキストの可
読性を向上させ、token（分割不能な字句単位）同士を区切
るために用いられるが、それ以外では意味を持たない。
White space code point は、任意の 2 つの token
の間、および入力の先頭または末尾に現れ得る。White
space code point は、
ECMAScript の white space code point は
| Code Points | 名称 | 略称 |
|---|---|---|
U+0009
|
CHARACTER TABULATION | <TAB> |
U+000B
|
LINE TABULATION | <VT> |
U+000C
|
FORM FEED (FF) | <FF> |
U+FEFF
|
ZERO WIDTH NO-BREAK SPACE | <ZWNBSP> |
| 一般カテゴリ “Space_Separator” に属する任意の code point | <USP> |
U+0020 (SPACE) および U+00A0 (NO-BREAK SPACE) code point は <USP> の一部である。
White space code point と同様に、line
terminator code point もソーステキストの可読性を向
上させ、token（分割不能な字句単位）同士を区切るために
用いられる。しかし、white space code point とは異
なり、line terminator は構文文法の振る舞いにいくら
か影響を与える。一般に、line terminator は任意の 2
つの token の間に現れ得るが、構文文法により禁止され
ている箇所がいくつかある。line terminator は、自動
セミコロン挿入の処理にも影響する
（
line terminator は
line terminator は、正規表現における \s
class で一致される white space code point の集合
に含まれる。
ECMAScript の line terminator code point は
| Code Point | Unicode 名 | 略称 |
|---|---|---|
U+000A
|
LINE FEED (LF) | <LF> |
U+000D
|
CARRIAGE RETURN (CR) | <CR> |
U+2028
|
LINE SEPARATOR | <LS> |
U+2029
|
PARAGRAPH SEPARATOR | <PS> |
Comment は、単一行でも複数行でもよい。複数行 comment は入れ子にできない。
単一行 comment は // マーカーか
ら行末までのすべての code point から構成される。しか
し、行末の
Comment は white space のように振る舞い、捨てら
れる。ただし、
この節のいくつかの生成規則には、
Hashbang Comment は位置依存であり、他の種類の comment と同様、構文文法のための入力要素列から捨てられ る。
この標準は特定の code point の追加を規定する:
U+0024 (DOLLAR SIGN) および U+005F (LOW
LINE) は
非終端記号
非終端記号 _ を導出する。
Unicode property “ID_Start” および “ID_Continue” を持つ code point の集合は、それ ぞれ、Unicode property “Other_ID_Start” および “Other_ID_Continue” を持つ code point を含 む。
Unicode エスケープシーケンスは
\ はいかな
る code point も与えない。\
Unicode Standard に従って正準同値である 2 つの
The
The
keyword と
は、fixed width font により、文
字どおりに現れる。ECMAScript の keyword には if、
while、async、await など多数が含まれる。
reserved
word とは、識別子として使用できない
if および while
は reserved word である。await は async
function および module の内部でのみ予約される。
async は予約されない; それは変数名または文ラベルと
して制限なく使用できる。
この仕様は、文法生成規則と await
および yield を除くすべては、無条件に予約される。
await および yield に対する例外は、
Math、window、toString、および _
のように、常に識別子として許可され、keyword ではな
いもの;
await および yield を除く、以下に列挙さ
れる
await および yield、すなわち、文脈に応じ
て識別子として許可されるもの;
let、static、
implements、interface、package、
private、protected、および public;
常に識別子として許可されるが、as、async、from、get、
meta、of、set、および target。
conditional keyword または contextual keyword という用語は、最後の 3 つのカテゴリに 属する keyword、すなわち、ある文脈では識別子として使 用でき、別の文脈では keyword として使用されるものを指 して用いられることがある。
\
\
els\u{65} と綴って "else" という名前の変数を宣言
することはできない。
enum は現在この仕様において keyword として
使用されていない。これは将来予約語であり、将来の言
語拡張における keyword としての使用のために確保されて
いる。
同様に、implements、interface、
package、private、protected、および
public は
たとえば: 3in は error であり、2 つの入
力要素 3 と in ではない。
数値リテラルは
The
文字列リテラルは、単引用符または二重引用符で囲まれた
0 個以上の Unicode code point である。Unicode
code point は escape sequence を用いて表現するこ
ともできる。文字列リテラルには、閉じ引用符の code
point、U+005C (REVERSE SOLIDUS)、U+000D
(CARRIAGE RETURN)、および U+000A (LINE FEED)
を除くすべての code point を文字どおりに現すことが
できる。任意の code point は escape sequence の
形で現すことができる。文字列リテラルは ECMAScript
String 値へ評価される。これらの String 値を生成する
際、Unicode code point は
非終端記号
<LF> および <CR> は、空の code
point 列を生成する \n や \u000A のような escape
sequence を用いることである。
文字列リテラルが、その後に続く
function invalid() { "\7"; "use strict"; }The
文字列リテラルは
| 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 |
\
|
正規表現リテラルは、その literal が評価されるたび
に RegExp object へ変換される入力要素である
（=== と比較して真
になることのない正規表現オブジェクトへ評価される。
RegExp object は、new RegExp によって、または
RegExp
以下の生成規則は、正規表現リテラルの構文を記述し、入
力要素 scanner により正規表現リテラルの終端を見つけ
るために用いられる。
実装は、
正規表現リテラルは空であってはならない; 空の正規表現
リテラルを表す代わりに、code unit 列 // は単一行
comment を開始する。空の正規表現を指定するには、
/(?:)/ を用いる。
The
The
The
The
ほとんどの ECMAScript の文および宣言は、セミコロ ンで終端しなければならない。そのようなセミコロンは、ソー ステキスト中に常に明示的に現れてよい。しかし便宜のため、 特定の状況では、そのようなセミコロンはソーステキストから 省略してよい。これらの状況は、そのような状況においてセミ コロンがソースコード token 列に自動的に挿入される、と 述べることにより記述される。
以下の規則において、“token” とは、現在の字句目標
記号を用いて
セミコロン挿入には 3 つの基本規則がある:
ソーステキストを左から右へ parse していると き、文法のいかなる生成規則によっても許可されない token （offending token と呼ぶ）に遭遇した場 合、次の条件の 1 つ以上が真であれば、その offending token の前にセミコロンが自動的に挿入される:
} である。
) であり、かつ挿入され
たセミコロンが do-while 文
（
ただし、これらの規則には追加の最優先条件がある: そ
のセミコロンが empty statement として parse され
てしまう場合、またはそのセミコロンが for 文
（
文法における制限付き生成規則は、次のものだけである:
これらの制限付き生成規則の実際上の効果は次のとおりで ある:
++ または -- token を後置
演算子として扱う位置で、それに遭遇し、かつ直前の
token と ++ または -- token の間
に少なくとも 1 個の ++ または -- token の前にセミ
コロンが自動的に挿入される。
continue、break、return、
throw、または yield token に遭遇
し、次の token より前に
continue、break、return、
throw、または yield token の後
にセミコロンが自動的に挿入される。
=> token より前に async token の後、function、
( token よ
り前に async token
は後続 token と同じ式または class
element の一部としては扱われない。
async token の後、* token より前に
ECMAScript プログラマへの実際上の助言は次のとお りである:
++ または -- 演算子は、その被
演算子と同じ行に置くべきである。
return または throw 文における
yield 式におけ
る return、throw、または yield
token と同じ行で始めるべきである。
break または continue 文の
break または
continue token と同じ行に置くべきで
ある。
=> は同じ行に置くべきである。
async token は、その直後の
token と同じ行に置くべきである。
次のソース
{ 1 2 } 3は、自動セミコロン挿入規則を考慮しても、 ECMAScript 文法における妥当な文ではない。これに対し、 次のソース
{ 1
2 } 3もまた妥当な ECMAScript 文ではないが、自動セミコ ロン挿入によって次のように変換される:
{ 1
;2 ;} 3;これは妥当な ECMAScript 文である。
次のソース
for (a; b
)
は妥当な ECMAScript 文ではなく、for 文の
header に必要なセミコロンであるため、自動セミコロン挿
入によって変更もされない。自動セミコロン挿入は、for
文の header にある 2 つのセミコロンのいずれかを挿入
することは決してない。
次のソース
return
a + bは、自動セミコロン挿入によって次のように変換される:
return;
a + b;
式 a + b は return 文によって返される値
としては扱われない。なぜなら return とそれを分離しているからである。
次のソース
a = b
++cは、自動セミコロン挿入によって次のように変換される:
a = b;
++c;
token ++ は、変数 b に適用される後置演
算子としては扱われない。なぜなら b と ++ の間
に
次のソース
if (a > b)
else c = d
は妥当な ECMAScript 文ではなく、else
token の前で自動セミコロン挿入によって変更もされな
い。たとえその地点で文法のいかなる生成規則も適用できな
くても、自動挿入されたセミコロンは empty statement
として parse されてしまうからである。
次のソース
a = b + c
(d + e).print()は、自動セミコロン挿入によって変換されない。な ぜなら 2 行目の先頭にある括弧付き式は、関数呼出しの引数 list として解釈できるからである:
a = b + c(d + e).print()代入文が左丸括弧で始まらなければならない状況では、プ ログラマは自動セミコロン挿入に頼るのではなく、先行する文 の末尾に明示的なセミコロンを与えるのがよい考えである。
ECMAScript プログラムは、自動セミコロン挿入に依存 することで、非常に少ないセミコロンを用いるスタイルでも記 述できる。上で述べたように、セミコロンはすべての改行位置 に挿入されるわけではなく、自動セミコロン挿入は line terminator をまたぐ複数 token に依存し得る。
新しい構文機能が ECMAScript に追加されると、その前 にある自動セミコロン挿入に依存する行について、parse 時 に文法生成規則が変化するような追加の文法生成規則が加えら れ得る。
この節の目的において、自動セミコロン挿入の事例が興味 深いと見なされるのは、それが、先行するソーステキストに応 じてセミコロンが挿入される場合とされない場合がある場所で ある場合である。この節の残りでは、このバージョンの ECMAScript における自動セミコロン挿入の興味深い事例を いくつか記述する。
()。セミコ
ロンがない場合、2 行は together で
[)。セミコ
ロンがない場合、2 行は `)。
セミコロンがない場合、2 行は together でタグ付き
Template（+ または -。
セミコロンがない場合、2 行は together で対応する二項
演算子の使用として解釈される。/
ECMAScript は “[no
この節の残りでは、このバージョンの ECMAScript に
おいて “[no