ECMAScript仕様書の読み方

1. 序章

毎日少しずつECMAScript仕様書を読むのは健康に良いと決心したあなたへ。新年の抱負だったかもしれませんし、医者の処方だったかもしれません。理由は何であれ、ようこそ！

注: この文書では、「ECMAScript」という用語は仕様書そのものを指すためだけに使い、それ以外の場所では「JavaScript」と表記します。ただし、どちらも同じものを指します。（ECMAScriptとJavaScriptの歴史的な違いもありますが、それは本書の範囲外ですし、Googleで簡単に調べることができます。）

1.1. なぜECMAScript仕様書を読むべきか

ECMAScript仕様書は、すべてのJavaScript実装の挙動を定義する権威ある情報源です。ブラウザ[WHATISMYBROWSER]、Node.jsサーバー[NODEJS]、IoTデバイス[JOHNNY-FIVE]など、どこであっても仕様書が基準です。JavaScriptエンジンの開発者は、他のエンジンと同じように新機能が意図通り動作するか確認するため、仕様書に依存しています。

しかし、仕様書の有用性は「JavaScriptエンジンの開発者」と呼ばれる神話的な存在だけに限定されません。実際、仕様書は一般のJavaScriptコーダーであるあなたにも役立つのです。それに気づいていないだけです。

ある日、職場で次のような不思議な状況に遭遇したとします。

> Array.prototype.push(42)
1
> Array.prototype
[ 42 ]
> Array.isArray(Array.prototype)
true
> Set.prototype.add(42)
TypeError: Method Set.prototype.add called on incompatible receiver #<Set>
    at Set.add (<anonymous>)
> Set.prototype
Set {}

プロトタイプ上でメソッドが動作する場合もあれば、別のプロトタイプでは動作しない場合もあり、困惑するでしょう。Googleは肝心な時に役立たず、Stack Overflowも同様です。

仕様書を読むことで解決できます。

また、悪名高い緩い等価演算子（==）が実際にはどのように機能するのか疑問に思うかもしれません（ここで「function」を緩く使っています[WAT]）。真面目なソフトウェアエンジニアとしてMDNで調べても、長い説明文が逆に混乱を招きます[MDN]。

仕様書を読むことで解決できます。

一方で、JavaScript初心者にはECMAScript仕様書の読解はおすすめしません。JavaScriptが初めてなら、まずはウェブで遊んでみてください！ウェブアプリを作ったり、JavaScriptベースの見守りカメラを作ったり、何でもいいので体験してみてください。そして、JavaScriptの落とし穴を十分経験したり、JavaScriptで悩まなくてもよくなったら本書に戻ってきてください。

さて、仕様書は言語やプラットフォームの仕組みを理解する上で非常に役立つツールだと分かりました。でも、ECMAScript仕様書には具体的に何が含まれるのでしょうか？

1.2. ECMAScript仕様書に含まれるもの・含まれないもの

教科書的な答えは「言語の機能だけがECMAScript仕様書に含まれる」です。しかし、これでは「JavaScriptの機能はJavaScriptだ」と言っているだけで、役立ちません。私はトートロジー（同語反復）は好みません[XKCD-703]。

そこで、よくJavaScriptアプリで見かけるものをリストアップし、それぞれが言語機能なのかどうかを説明します。

1.3. 先に進む前に、どこにECMAScript仕様書があるのか？

「ECMAScript specification」をGoogle検索すると、多くの結果が出てきて、どれも正式な仕様書だと主張しています。どれを読めばいいのでしょうか？

まとめ：ほとんどの場合、tc39.es/ecma262/で公開されている仕様書が本命です[ECMA-262]。

詳細：

ECMAScript言語仕様は、多様なバックグラウンドを持つ人々からなるEcma International Technical Committee 39（通称TC39[TC39]）によって策定されています。TC39はtc39.esで最新の仕様書を管理しています[ECMA-262]。

ややこしいのは、TC39が毎年仕様書のスナップショットを撮り、その年のECMAScript言語標準とし、版番号を付けることです。例えば、ECMAScript® 2019 Language Specification (ECMA-262, 第10版)[ECMA-262-2019]（ES10やES2019として知られる）は、2019年6月時点のtc39.es[ECMA-262]の内容をアーカイブ用に凍結・PDF化したものです。

したがって、2019年6月のブラウザしか使わない場合やアーカイブ目的でなければ、常にtc39.esの最新仕様書[ECMA-262]を参照するべきです。ただし、古いブラウザやNode.jsのバージョンをサポートする必要がある場合は、古い仕様書を参照すると役立つかもしれません。

注: ISO/IECもECMAScript言語標準をISO/IEC 22275[ISO-22275-2018]として再公開していますが、気にしなくて大丈夫です。内容は基本的に[ECMA-262]へのリンクです。

1.4. 仕様のナビゲート

ECMAScript仕様書は非常に多くの内容を扱っています。著者たちは論理的に分割しようと努力していますが、それでも膨大な文章です。

個人的には、仕様書を5つのパートに分けて考えています：

• 慣例と基本事項（「Numberとは何か？ 仕様書で『TypeError例外を投げる』とはどういう意味か？」）

• 言語の文法（「for-inループはどう書くか？」）

• 言語の静的意味論（「var文で変数名がどう決まるか？」）

• 言語の実行時意味論（「for-inループはどう実行されるか？」）

• API（「String.prototype.substring()は何をするか？」）

しかし、仕様書自体はこのように整理されていません。最初の項目は§5 記法規約から§9 通常・特殊オブジェクトの挙動まで、次の3つは§10 ECMAScript言語: ソースコードから§15 ECMAScript言語: スクリプトとモジュールまでに交互に現れます。例えば、

• §13.6 if 文 文法

  • §13.6.1-6 静的意味論

  • §13.6.7 実行時意味論

• §13.7 繰り返し文 文法

  • §13.7.1 共通の静的・実行時意味論

  • §13.7.2 do-while文

    • §13.7.2.1-5 静的意味論

    • §13.7.2.6 実行時意味論

  • §13.7.3 while文

    • ...

APIは§18 グローバルオブジェクトから§26 リフレクションまでに散らばっています。

ここで強調したいのは、仕様書を頭から最後まで読む人は絶対にいないということです。自分が知りたい部分だけを探し、そのセクションの必要な範囲だけを読めば十分です。まず自分の疑問が上記の5つのどれに関係するかを考え、判断に迷う場合は「この内容はいつ評価されるか？」と自問してみてください。仕様書のナビゲートは慣れるほど簡単になりますので、心配しないでください。

2. 実行時意味論

言語やAPIの実行時意味論は仕様書の中でも最大の部分であり、多くの人が疑問に思うところでもあります。

全体として、仕様書のこれらのセクションを読むのは比較的分かりやすいですが、仕様書では多くの略記が使われており、初心者には少しややこしいかもしれません（少なくとも私にはそうでした）。いくつかの慣例を説明し、それを使って物事の仕組みを調べる流れを紹介します。

2.1. アルゴリズム手順

ECMAScriptの実行時意味論は、疑似コードに似た（しかしより厳密な）アルゴリズム手順の列によって記述されます。

さらに詳しくは：§5.2 アルゴリズムの慣例

2.2. 抽象操作

仕様書では、関数のようなものが呼び出される記述が時々現れます。Boolean() 関数の最初の手順は：

この「ToBoolean」関数は抽象操作と呼ばれます。抽象的というのは、JavaScriptコードとして公開される関数ではなく、仕様書の著者が同じことを繰り返し書くのを避けるために発明した記法だからです。

注: 今はToBooleanの前にある「!」について気にしなくて大丈夫です。後で§2.4 Completion Record・?と!で説明します。

さらに詳しくは：§5.2.1 抽象操作

2.3. [[This]]とは

時々、[[記法]]が「Let proto be obj.[[Prototype]].」のように使われることがあります。この記法は文脈によって意味が異なりますが、「JavaScriptコードからは観測できない内部プロパティ」を指す理解で十分です。

厳密には3つの意味があり、仕様書の例で説明しますが、今は飛ばしても構いません。

2.3.1. Recordのフィールド

ECMAScript仕様では、Recordという用語を、固定されたキーを持つキー・バリューのマップ（C言語の構造体のようなもの）を指すために使います。Recordの各キー・バリューのペアはフィールドと呼ばれます。Recordは仕様書でのみ登場し、実際のJavaScriptコードでは使われません。そのため、[[記法]]でフィールドを参照します。

Recordのさらに具体的な例は次の§2.4 Completion Record・?と!で説明します。

さらに詳しくは：§6.2.1 List・Record仕様型

2.3.2. JavaScriptオブジェクトの内部スロット

JavaScriptオブジェクトは、仕様書でデータを保持するために使われる内部スロットを持つことがあります。Recordのフィールド同様、内部スロットもJavaScriptから直接観測できませんが、一部はGoogle ChromeのDevToolsなど実装依存のツールで確認できる場合もあります。そのため、[[記法]]で内部スロットを表現します。

内部スロットの詳細は§2.5 JavaScriptオブジェクトで解説します。今は用途を気にせず、次の例だけ覚えておいてください。

注: オブジェクトの内部スロットとRecordのフィールドは見た目は同じですが、記法の前置詞（ドットの前の部分）がオブジェクトかRecordかで区別できます。通常、文脈から判断できます。

2.3.3. JavaScriptオブジェクトの内部メソッド

JavaScriptオブジェクトには、内部メソッドと呼ばれるものもあります。内部スロットと同様に、これらの内部メソッドはJavaScriptから直接観察することはできません。そのため、[[記法]]で内部メソッドを表現するのが適切です。

内部メソッドの詳細については§ 2.5 JavaScriptオブジェクトで説明します。今は用途について深く考えなくてもよいですが、次の例に注目してください。

注: この[[記法]]の三つ目の意味は、関数呼び出しのような形で見分けることができます。

2.4. Completion Record；?および!

ECMAScript仕様書のすべての実行時意味論は、その結果を報告するCompletion Recordを明示的または暗黙的に返します。このCompletion Recordは、三つのRecordフィールドを持つことができます：

• [[Type]]（normal、return、throw、 break、またはcontinue）

• [[Type]]がnormal、 return、 またはthrowの場合は、[[Value]]（返却値やthrowされた値）も持つことができます。

• [[Type]]がbreak またはcontinueの場合は、実行がどのラベルに対してbreak/continueしたかを示すlabel情報（[[Target]]）を持つことができます。

注: 二重括弧はRecordのフィールドを示します。§2.3.1 Recordのフィールドで記法の基本を解説しています。

Completion Recordの[[Type]]がnormalの場合、それはnormal completionと呼ばれます。それ以外はすべてabrupt completionとも呼ばれます。

ほとんどの場合、abrupt completionのうち、[[Type]]がthrowのものだけを扱うことになります。他の三つは特定の構文要素の評価過程でしか登場しません。実際、組み込み関数の定義でこれらが現れることはなく、break/continue/returnは関数の境界を越えて動作しないからです。

さらに詳しくは：§6.2.3 Completion Record仕様型

Completion Recordの定義により、JavaScriptでよく見られるtry-catchによるエラーのバブリングのような挙動は仕様書にはありません。実際、エラー（より厳密にはabrupt completion）は明示的に処理されます。

略記を使わない場合、計算結果かエラーを返す可能性がある抽象操作の普通の呼び出しは、次のような記述になります：

int result = abstractOp();              // Step 1
if (result < 0)                         // Step 2
  return result;                        // Step 2 (continued)
                                        // Step 3 is unneeded
// func() succeeded; carrying on...     // Step 4

このような定型的な手順を減らすため、ECMAScript仕様書の著者たちはいくつかの略記法を導入しました。ES2016以降は、同じ内容が次のいずれかの方法で書けます：

あるいは、さらに簡潔に、特別な疑問符（?）記法を使うこともできます：

特定のAbstractOp呼び出しでabrupt completionが絶対に返らない場合は、仕様の意図を明確にするために感嘆符（!）が使われます：

さらに詳しくは：§5.2.3.4 ReturnIfAbrupt略記

2.5. JavaScriptオブジェクト

ECMAScriptでは、すべてのオブジェクトが特定のタスクを行うための内部メソッドを持っています。すべてのオブジェクトが持つ内部メソッドのいくつかを挙げます：

• [[Get]]（オブジェクトのプロパティ取得、例：obj.prop）

• [[Set]]（オブジェクトのプロパティ設定、例：obj.prop = 42;）

• [[GetPrototypeOf]]（オブジェクトのプロトタイプ取得、例：Object.getPrototypeOf(obj)）

• [[GetOwnProperty]]（オブジェクト自身のプロパティ記述子取得、例：Object.getOwnPropertyDescriptor(obj, "prop")）

• [[Delete]]（オブジェクトのプロパティ削除、例：delete obj.prop）

(完全な一覧は§6.1.7.2 オブジェクトの内部メソッドと内部スロット参照)

この定義により、関数オブジェクト（または単に「関数」）は、[[Call]]内部メソッド（場合によっては[[Construct]]内部メソッドも）を追加で持つオブジェクトです。そのため、呼び出し可能オブジェクトとも呼ばれます。

仕様書ではすべてのオブジェクトを二つに分類します：普通のオブジェクトと特殊なオブジェクトです。ほとんどのオブジェクトは普通のオブジェクトであり、すべての内部メソッドが§9.1 普通のオブジェクトの内部メソッドと内部スロットで定義されているデフォルトのものです。

しかし、ECMAScript仕様書では、これらの内部メソッドのデフォルト実装をオーバーライドできる特殊オブジェクトも定義されています。特殊オブジェクトができることには最低限の制約しかありませんが、一般的には仕様に反しない範囲で、オーバーライドされた内部メソッドはかなり自由な振る舞いが可能です。

> const arr = [0, 1, 2, 3];
> console.log(arr);
[ 0, 1, 2, 3 ]
> arr.length = 1;
> console.log(arr);
[ 0 ]
> console.log(Object.getOwnPropertyDescriptor([], "length"));
{ value: 1,
  writable: true,
  enumerable: false,
  configurable: false }

> console.log(Object.getOwnPropertyDescriptor(new Map(), "size"));
undefined
> console.log(Object.getOwnPropertyDescriptor(Map.prototype, "size"));
{ get: [Function: get size],
  set: undefined,
  enumerable: false,
  configurable: true }

ECMAScript仕様書では、他の仕様が独自の特殊なオブジェクトを定義することも認めています。ブラウザがクロスオリジンAPIアクセスに制限を設ける仕組みもこのメカニズムで規定されており（WindowProxy）[HTML]）、JavaScriptプログラマーがProxyAPIで独自の特殊オブジェクトを作ることもできます。

JavaScriptオブジェクトは、特定の値を保持するための内部スロットも持つことがあります。私は内部スロットをObject.getOwnPropertySymbols()でも見つけられないシンボル名のプロパティのようなものと考えています。普通のオブジェクトも特殊なオブジェクトも内部スロットを持つことができます。

オブジェクト・内部メソッド・内部スロットの関係性は、古典的なオブジェクト指向的観点で考えることもできます。「オブジェクト」はいくつかの内部メソッドを実装するべきインターフェースのようなものです。普通のオブジェクトはデフォルト実装を提供し、特殊なオブジェクトはこれらを部分的または全部オーバーライドできます。一方、内部スロットはオブジェクトのインスタンス変数のようなもので、そのオブジェクトの実装詳細を表します。

これらの関係は、次のUML図でまとめられています（クリックで拡大）：

2.6. 例: String.prototype.substring()

これまで仕様書の構成や書き方についてかなり理解できたので、実際に練習してみましょう！

次のような疑問を持ったと仮定します：

コードを実行せずに、次のコード片は何を返しますか？

String.prototype.substring.call(undefined, 2, 4)

これはなかなか難しい質問です。主に2つの可能性が考えられます：

1. String.prototype.substring() がまずundefinedを文字列"undefined"に変換し、その文字列の2番目と3番目（すなわち区間[2, 4)）の文字を取得して結果として"de"を返す

2. 一方で、String.prototype.substring() がエラーを投げる可能性もあり、undefinedを入力として拒否することも考えられます。

残念ながら、MDN でも、this値が文字列でない場合の動作についてはあまり記載がありません。

ここで仕様書の出番です！ 仕様書の左上の検索ボックスでsubstringと入力すると、§21.1.3.22 String.prototype.substring ( start, end )にたどり着き、そこに関数の正規の仕様が記載されています。

アルゴリズムの手順を読む前に、まず既知のことを考えましょう。str.substring()が通常どのように動作するかは、与えられた文字列の一部を返すという基本は知っているはずです。今分からないのは、this値がundefinedの時の挙動です。なので、this値に関するアルゴリズムの手順を重点的に探します。

幸運にも、String.prototype.substring()のアルゴリズムの最初の手順がまさにthis値を処理しています：

1. Oに? RequireObjectCoercible(this value)を代入する。

?略記が使われているので、RequireObjectCoercible抽象操作が例外を投げる場合があることが分かります。もし例外を投げないなら!が使われているはずです。実際、もし例外が投げられれば、先程の2つ目の仮説と一致します！期待を込めて、RequireObjectCoercibleの中身を確認します。

RequireObjectCoercible抽象操作は少し特殊です。他の抽象操作とは違い、手順ではなく表で定義されています：

引数の型	結果
Undefined	TypeError例外を投げる。
...	...

ともかく、Undefined（今回渡したthis値の型）に対応する行には、RequireObjectCoercibleが例外を投げるべきと記載されています。そして関数の定義に?記法が使われていることで、投げられた例外が関数呼び出し元まで伝播することが分かります。ビンゴ！

つまり答えは：このコード片はTypeError例外を投げます。

TypeError: String.prototype.substring called on null or undefined

TypeError: can’t convert undefined to object

TypeError: String.prototype.substring: 'this' is null or undefined

2.7. 例: Boolean()およびString()は例外を投げることがあるか？

ミッションクリティカルなコードを書く際は、例外処理を意識した設計が重要です。そのため「ある組み込み関数は例外を投げることがあるのか？」という疑問はよく考察されます。

この例では2つの言語組み込み関数Boolean()とString()について、この疑問に答えてみます。ここでは直接呼び出しのみ対象とし、new Boolean()やnew String()のようなボックス化オブジェクトは除外します（これはJavaScriptで最も避けるべき機能の一つであり、ほぼすべてのJSスタイルガイドで推奨されていません[YDKJS]）。

仕様書でBoolean() のセクションを確認すると、アルゴリズムは比較的短いようです：

ただし、実はOrdinaryCreateFromConstructorまわりで少し複雑な処理があります。また、3番目の手順で?略記が使われているので、場合によっては例外が投げられるかもしれません。詳しく見てみましょう。

手順1ではvalue（関数引数）をBoolean値に変換しています。ここでは?や!略記はありませんが、通常Completion Record略記がなければ!と同じ意味になります。つまり、手順1は例外を投げません。

手順2はNewTargetがundefinedかどうかを確認します。NewTargetは、ES2015で追加されたnew.targetメタプロパティに相当し、new Boolean()呼び出し（この場合はBoolean）と、Boolean()呼び出し（この場合はundefined）を区別できます。今回は直接呼び出しだけを考えているので、NewTargetは必ずundefinedとなり、アルゴリズムはすぐにbを返します。

つまり、Boolean()をnewなしで呼ぶ場合、アルゴリズムの最初の2つの手順しか実行されず、どちらも例外を投げることはありません。したがって、Boolean()はどんな入力でも例外を投げません。

次にString()を見てみましょう：

先ほどBoolean() で行った分析から、NewTargetは今回も必ずundefinedとなり、最後の手順は考慮不要です。また、TypeやSymbolDescriptiveStringも安全ですが、?がToString呼び出しの前に付いているのが気になります。詳しく見てみましょう。

先ほど見たRequireObjectCoercible同様、ToString(argument)も表で定義されています：

引数の型	結果
Undefined	"undefined"を返す。
Null	"null"を返す。
Boolean	argumentがtrueなら"true"を返す。 argumentがfalseなら"false"を返す。
Number	NumberToString(argument)を返す。
String	argumentを返す。
Symbol	TypeError例外を投げる。
Object	次の手順を実行： primValueに? ToPrimitive(argument, hint String)を代入する。 ? ToString(primValue)を返す。

String()でToStringが呼ばれる時点で、valueはSymbol以外の値であることが保証されています。ただしObjectの場合は、?が2箇所残っています。リンクを辿ってToPrimitiveなどを見ると、Objectの場合はエラーが発生する可能性がいろいろあることが分かります：

// 仕様のスタックトレース:
//   OrdinaryGet 手順8。
//   普通のオブジェクトの[[Get]]() 手順1。
//   GetV 手順3。
//   GetMethod 手順2。
//   ToPrimitive 手順2.d。

String({
  get [Symbol.toPrimitive]() {
    throw new Error("Breaking JavaScript");
  }
});

// 仕様のスタックトレース:
//   GetMethod 手順4。
//   ToPrimitive 手順2.d。

String({
  get [Symbol.toPrimitive]() {
    return "Breaking JavaScript";
  }
});

// 仕様のスタックトレース:
//   ToPrimitive 手順2.e.i。

String({
  [Symbol.toPrimitive]() {
    throw new Error("Breaking JavaScript");
  }
});

// 仕様のスタックトレース:
//   ToPrimitive 手順2.e.iii。

String({
  [Symbol.toPrimitive]() {
    return { "breaking": "JavaScript" };
  }
});

// 仕様のスタックトレース:
//   OrdinaryToPrimitive 手順5.b.i。
//   ToPrimitive 手順2.g。

String({
  toString() {
    throw new Error("Breaking JavaScript");
  }
});

// 仕様のスタックトレース:
//   OrdinaryToPrimitive 手順5.b.i。
//   ToPrimitive 手順2.g。

String({
  valueOf() {
    throw new Error("Breaking JavaScript");
  }
});

// 仕様のスタックトレース:
//   OrdinaryToPrimitive 手順6。
//   ToPrimitive 手順2.g。

String(Object.create(null));

つまりString()については、プリミティブ値では例外を投げませんが、Objectの場合はエラーを投げることがあり得ます。

2.8. 例: typeof演算子

ここまでAPI関数ばかり分析してきましたが、違うものも試してみましょう。

執筆予定。 <https://github.com/TimothyGu/es-howto/issues/2>

用語集

共通抽象操作

ArrayCreate ( length [ , proto ] ) (仕様)

lengthの長さを持ち、[[Prototype]] 内部スロットの値としてprotoを持つ配列オブジェクトを作成します。protoが指定されていない場合、%ArrayPrototype%（現在のレルム）が使用されます。Arrayコンストラクターおよびそのすべてのプロパティがモンキーパッチされておらず、protoが指定されていないか%ArrayPrototype%（現在のレルム）の場合、new Array(length)と同等です。

Call ( F, V [ , argumentsList ] ) (仕様)

Construct ( F [ , argumentsList [ , newTarget ] ] ) (仕様)

Get ( O, P ) (仕様)

HasProperty ( O, P ) (仕様)

FまたはOに対応する内部メソッドを、残りの引数を渡して呼び出します。Reflectオブジェクトの対応するメソッドと同等です。

DefinePropertyOrThrow ( O, P, desc ) (仕様)

DeletePropertyOrThrow ( O, P ) (仕様)

それぞれ[[DefineOwnProperty]]および[[Delete]]の内部メソッドを、残りの引数を渡してO上で呼び出し、操作が失敗して内部メソッドがfalseを返した場合は例外を投げます。

GetV ( V, P ) (仕様)

Vが必要ならToObject後にGet(V, P)を返します。V[P]と同等です。

HasOwnProperty ( O, P ) (仕様)

OがPという自身のプロパティを持つかどうかを、O.[[GetOwnProperty]](P)を呼び出して判定します。Object.prototype.hasOwnProperty.call(O, P)と同等です。

Invoke ( V, P [ , argumentsList ] ) (仕様)

V上でPという名前のメソッドをargumentsListを用いて呼び出します。V[P](...argumentsList)と同等です。 ここではCallとは異なり、Pはプロパティキーです。

IsArray ( argument ) (仕様)

argumentがArray 特殊オブジェクトか、argumentがProxy 特殊オブジェクトの場合は、その最も内側の[[ProxyTarget]] 内部スロットがArray 特殊オブジェクトかどうかを返します。Array.isArray(argument)と同等です。

IsCallable ( argument ) (仕様)

argumentが呼び出し可能オブジェクト（関数オブジェクト）かどうかを返します。typeof argument === 'function'と同等ですが、document.allは例外です（特殊オブジェクトで特別な挙動を持ちます。詳細は§B.3.7 [[IsHTMLDDA]]内部スロット参照）。

IsConstructor ( argument ) (仕様)

argumentが[[Construct]] 内部メソッドを持つ関数オブジェクトかどうかを返します。

ReturnIfAbrupt ( argument ) (仕様)

argumentがabrupt completion（例外など）であれば、そのabrupt completionを返し（例外を伝播させる）、そうでなければargumentがnormal completionであることを確認し、Completion Recordを展開してargumentをargument.[[Value]]に設定します。

詳細は：§2.4 Completion Record・?と!参照。

StringCreate ( value, prototype ) (仕様)

文字列valueに対応するボックス化されたString オブジェクトを返します。生成されたオブジェクトの[[Prototype]]内部スロットはprototypeです。prototypeが%StringPrototype%（現在のレルム）の場合、new String(value)と同等です。

ToBoolean ( argument ) (仕様)

argumentをBooleanに強制変換して返します。!!argumentと同等です。

ToInteger ( argument ) (仕様)

ToNumber(argument)で得た値を0に丸めて整数にして返します。Math.trunc(argument)と同等です。

ToInt8 ( argument ) (仕様)

ToUint8 ( argument ) (仕様)

ToInt16 ( argument ) (仕様)

ToUint16 ( argument ) (仕様)

ToInt32 ( argument ) (仕様)

ToUint32 ( argument ) (仕様)

argumentを指定されたビット数と符号で整数に変換し、丸めて返します。

ToUint8Clamp ( argument ) (仕様)

argumentを丸めとクランプによって[0, 255]の範囲の整数に変換して返します。

ToNumber ( argument ) (仕様)

argumentをNumber型に強制変換して返します。+argumentと同等です。

ToObject ( argument ) (仕様)

argumentをObjectに強制変換して返します。必要に応じてボックス化されたプリミティブオブジェクトを使います。Object(argument)（ただしargumentがundefinedまたはnullの場合は除く）と同等です。

ToPrimitive ( input [ , PreferredType ] ) (仕様)

inputをプリミティブ（非オブジェクト）値に強制変換して返します。オプションでPreferredType型ヒントを使います。具体的な意味論はPreferredTypeによって異なります。

ToString ( argument ) (仕様)

argumentをStringに強制変換して返します。`${argument}`と同等です。

注意：String(argument)やargument + ''は完全にToStringと同等ではありません。String()はSymbol値をその文字列表現に変換しますが、ToStringはSymbolで例外を投げます。加算演算子は値をStringに変換する際にargument[Symbol.toPrimitive]など他の関数を呼び出す場合があります。

Type ( argument ) (仕様)

argumentの型を返します。