2.3.1. ~mixinと~partialの利用-法

`~ifc~mixin$は、［ `属性$／`定数$／`演算$ ］を`複数^emの`~ifc$から共有することを許容する。 単独の~ifcを拡張することしか計画していないときは、 代わりに`部分的な~ifc$の利用を考慮することもあろう。 ◎ Interface mixins allow the sharing of attributes, constants, and operations across multiple interfaces. If you’re only planning to extend a single interface, you might consider using a partial interface instead.

例えば，次に代えて： ◎ For example, instead of:

interface mixin WindowSessionStorage {
  readonly attribute Storage sessionStorage;
};
Window includes WindowSessionStorage;

次のようにするなど： ◎ do:

partial interface Window {
  readonly attribute Storage sessionStorage;
};

加えて，共通的な利用事例 — ［ `属性$, `定数$, `演算$ ］たちが成す集合を［ ~window, ~worker ］両~文脈に`公開され$るようにするなど — を~targetにするため、 他の仕様により公開される`~ifc~mixin$を拡張することに依拠できる。 ◎ Additionally, you can rely on extending interface mixins exposed by other specifications to target common use cases, such as exposing a set of attributes, constants, or operations across both window and worker contexts.

例えば、 共通的にあるが冗漫な，次に代えて： ◎ For example, instead of the common but verbose:

interface mixin GlobalCrypto {
  readonly attribute Crypto crypto;
};

Window includes GlobalCrypto;
WorkerGlobalScope includes GlobalCrypto;

`部分的な~ifc~mixin$を利用すれば， `WindowOrWorkerGlobalScope$T `~ifc~mixin$を拡張できる： ◎ you can extend the WindowOrWorkerGlobalScope interface mixin using a partial interface mixin:

partial interface mixin WindowOrWorkerGlobalScope {
  readonly attribute Crypto crypto;
};

2.5.1. 定数

`定数@ （ `constant^en ）は、 定数~値を名前に束縛するために利用される，宣言 （ `Const$g に合致-） である。 定数は［ `~ifc$／`~callback~ifc$ ］に現れ得る。 ◎ A constant is a declaration (matching Const) used to bind a constant value to a name. Constants can appear on interfaces and callback interfaces.

過去においては，定数は、 主に，有名~整数~codeを列挙する~styleで定義されていた。 ~Web~platformは、 文字列の利用の支持を受けて，この設計~patternから離れつつある。 この特能を利用したいと望む編集者には、 先に進む前に `Intent to use Constants$fI した上で論交することを，強く勧める。 ◎ Constants have in the past primarily been used to define named integer codes in the style of an enumeration. The Web platform is moving away from this design pattern in favor of the use of strings. Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.

const `type^i `constant_identifier^i = 42;

`定数$の`識別子$は、 次に挙げるものと同じになってはナラナイ： ◎ The identifier of a constant＼

• 同じ［ `~ifc$／`~callback~ifc$ ］上で定義される別の［ `~ifc~mb$／`~callback~ifc~mb$ ］の識別子 ◎ must not be the same as the identifier of another interface member or callback interface member defined on the same interface or callback interface.＼
• `length^l ／ `name^l ／ `prototype^l ◎ The identifier also must not be “length”, “name” or “prototype”.

注記： これらの名前は、 ~JS言語束縛においては，`~ifc~obj$上に定義される~propの名前である。 ◎ Note: These three names are the names of properties that are defined on the interface object in the JavaScript language binding.

定数の型 （ `ConstType$g に合致-） は、 `~primitive型$でなければナラナイ。 【当の型に】`識別子$を利用する場合、 それは，~primitive型の`~typedef$を参照しなければナラナイ。 ◎ The type of a constant (matching ConstType) must not be any type other than a primitive type. If an identifier is used, it must reference a typedef whose type is a primitive type.

定数~宣言を成す `ConstValue$g は、 当の定数の値を次に挙げるいずれかとして与える： ◎ The ConstValue part of a constant declaration gives the value of the constant, which can be＼

• 真偽-~literal： `true^sym ／ `false^sym ◎ one of the two boolean literal tokens (true and false),＼
• `integer$g ◎ an integer token,＼
• `decimal$g ◎ a decimal token,＼
• 特別な浮動小数点~定数~値： `-Infinity^sym ／ `Infinity^sym ／ `NaN^sym ◎ or one of the three special floating point constant values (-Infinity, Infinity and NaN).

注記： 文字列や空~連列に加え，これらの値も［ 辞書~mbの`既定~値$diC ／ `随意~引数$の`既定~値$ ］を指定するために利用できる。 ［ 文字列 ／ 空~連列 `[]^sym ／ 既定の辞書 `{}^sym ］は、 `定数$の値としては利用できないことに注意。 ◎ Note: These values – in addition to strings and the empty sequence – can also be used to specify the default value of a dictionary member or of an optional argument. Note that strings, the empty sequence [], and the default dictionary {} cannot be used as the value of a constant.

真偽-~literal~token［ `true^sym ／ `false^sym ］は、 ~IDL `boolean$T 値［ `true^V ／ `false^V ］になる。 ◎ The value of the boolean literal tokens true and false are the IDL boolean values true and false.

`integer$g ~tokenの型は、 それを値に利用している［ 定数／辞書~mb／随意~引数 ］の型と同じである。 `integer$g ~tokenの値は、 `型＠#idl-types§にて与えられる，その型の値として妥当な範囲に入らなければナラナイ。 ◎ The type of an integer token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the integer token must not lie outside the valid range of values for its type, as given in § 2.13 Types.

`Infinity^sym, `-Infinity^sym, `NaN^sym のいずれかとして指定された定数~値は、 それを値に利用している［ 定数／辞書~mb／随意~引数 ］の型に依存して，単精度, 倍精度 いずれかの IEEE 754 浮動小数点数になり、 次に従って決定される： ◎ The value of a constant value specified as Infinity, -Infinity, or NaN is either an IEEE 754 single-precision floating point number or an IEEE 754 double-precision floating point number, depending on the type of the constant, dictionary member, or optional argument it is being used as the value for:

`unrestricted float$T 型の定数~値 `Infinity^sym ◎ Type unrestricted float, constant value Infinity

値は IEEE 754 単精度，正な無限大~値 ◎ The value is the IEEE 754 single-precision positive infinity value.

`unrestricted double$T 型の定数~値 `Infinity^sym ◎ Type unrestricted double, constant value Infinity

値は IEEE 754 倍精度，正な無限大~値 ◎ The value is the IEEE 754 double-precision positive infinity value.

`unrestricted float$T 型の定数~値 `-Infinity^sym ◎ Type unrestricted float, constant value -Infinity

値は IEEE 754 単精度，負な無限大~値 ◎ The value is the IEEE 754 single-precision negative infinity value.

`unrestricted double$T 型の定数~値 `-Infinity^sym ◎ Type unrestricted double, constant value -Infinity

値は IEEE 754 倍精度，負な無限大~値 ◎ The value is the IEEE 754 double-precision negative infinity value.

`unrestricted float$T 型の定数~値 `NaN^sym ◎ Type unrestricted float, constant value NaN

値は~bit~pattern `7fc00000^X の， IEEE 754 単精度 NaN ◎ The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000.

`unrestricted double$T 型の定数~値 `NaN^sym ◎ Type unrestricted double, constant value NaN

値は~bit~pattern `7ff8000000000000^X の， IEEE 754 倍精度 NaN ◎ The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000.

`decimal$g ~tokenの型は、 それを値に利用している［ 定数／辞書~mb／随意~引数 ］の型と同じになる。 `decimal$g ~tokenの値は、 `型＠#idl-types§にて与えられる，その型の値として妥当な範囲に入らなければナラナイ。 また、［ `Infinity^sym, `-Infinity^sym, `NaN^sym ］が［ `float$T や `double$T ］の値として利用してはナラナイ。 ◎ The type of a decimal token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the decimal token must not lie outside the valid range of values for its type, as given in § 2.13 Types. Also, Infinity, -Infinity and NaN must not be used as the value of a float or double.

`null^sym ~tokenの値は、 `~nullable型$に属する特別な `null^V 値である。 `null^sym ~tokenの型は、 それを値に利用している［ 定数／辞書~mb／随意~引数 ］の型と同じになる。 ◎ The value of the null token is the special null value that is a member of the nullable types. The type of the null token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of.

定数にアテガわれる値の型 %VT, ［ 定数／辞書~mb／随意~引数 ］自身の型 %DT は、 互換，すなわち ~OR ↓ を満たしていなければナラナイ： ◎ If VT is the type of the value assigned to a constant, and DT is the type of the constant, dictionary member or optional argument itself, then these types must be compatible, which is the case if＼

• %DT と %VT は一致する ◎ DT and VT are identical,＼
• ［ %DT は`~nullable型$である ］~AND［ %DT の`内縁~型$は %VT に一致する ］ ◎ or DT is a nullable type whose inner type is VT.

`定数$は、 それが現れる［ `~ifc$／`~callback~ifc$ ］の特定0の~instanceには結付けられない。 `定数$が~instanceにも公開されるかどうかは、 言語束縛に特有になる。 ◎ Constants are not associated with particular instances of the interface or callback interface on which they appear. It is language binding specific whether constants are exposed on instances.

[Exposed=Window]
interface A {
  const short rambaldi = 47;
};

定数に適用-可能な拡張d属性は ⇒＃ `CrossOriginIsolated$x, `Exposed$x, `SecureContext$x ◎ The following extended attributes are applicable to constants: [CrossOriginIsolated], [Exposed], and [SecureContext].

[Exposed=Window]
interface Util {
  const boolean DEBUG = false;
  const octet LF = 10;
  const unsigned long BIT_MASK = 0x0000fc00;
  const double AVOGADRO = 6.022e23;
};

2.5.2. 属性

`属性@ （ `attribute^en ） （ `inherit^sym `AttributeRest$g, `static^sym `OptionalReadOnly$g `AttributeRest$g, `stringifier^sym `OptionalReadOnly$g `AttributeRest$g, `OptionalReadOnly$g `AttributeRest$g, `AttributeRest$g いずれかに合致-） は、［ `~ifc~mb$／`~ns~mb$ ］であり，［ 所与の［ 型, `識別子$ ］を伴い，値を［ 検索取得できる／（一部の事例では）変更できる ］］ような~data~fieldを宣言するために利用される。 ◎ An attribute is an interface member or namespace member (matching inherit AttributeRest, static OptionalReadOnly AttributeRest, stringifier OptionalReadOnly AttributeRest, OptionalReadOnly AttributeRest, or AttributeRest) that is used to declare data fields with a given type and identifier whose value can be retrieved and (in some cases) changed.＼

`属性$には、 次に挙げる 2 種類がある： ◎ There are two kinds of attributes:

• `正則~属性$は、 次を宣言するために利用される ⇒ 当の［ ~ifc／~ns ］を実装している~objは、 所与の`識別子$を伴う~data~field~mbを有する ◎ regular attributes, which are those used to declare that objects implementing the interface will have a data field member with the given identifier

  interface `interface_identifier^i {
    attribute `type^i `identifier^i;
  };
  

• `静的~属性$は、 次を宣言するために利用される ⇒ 当の~ifcを実装している特定0の~objには結付けられない属性 ◎ static attributes, which are used to declare attributes that are not associated with a particular object implementing the interface

  interface `interface_identifier^i {
    static attribute `type^i `identifier^i;
  };
  

`static^sym ~keywordを伴う属性は、 `静的~属性$を宣言する。 他の属性は、 `正則~属性@ （ `regular attribute^en ） を宣言する。 `読専$な`正則~属性$には、 `~ifc~mb$の他にも，`~ns~mb$があることに注意。 ◎ If an attribute has no static keyword, then it declares a regular attribute. Otherwise, it declares a static attribute. Note that in addition to being interface members, read only regular attributes can be namespace members as well.

属性 %attr の `取得子~手続き@ （ `getter steps^en ）は、 次の形を成す~textを利用して導入されるベキである ⇒ “%attr 取得子~手続きは…” （［ ~listまたは~inline ］による記述が後続する） ◎ The getter steps of an attribute attr should be introduced using text of the form “The attr getter steps are:” followed by a list, or “The attr getter steps are to” followed by an inline description.

属性 %attr の `設定子~手続き@ （ `setter steps^en ）は、 次の形を成す~textを利用して導入されるベキである ⇒ “%attr 設定子~手続きは…” （［ ~listまたは~inline ］による記述が後続する） ◎ The setter steps of an attribute attr should be introduced using text of the form “The attr setter steps are:” followed by a list, or “The attr setter steps are to” followed by an inline description.

注記： `取得子~手続き$を定義するときは、 暗黙的に`this$V への~accessを有することになる。 `設定子~手続き$を定義するときは、 暗黙的に［ `this$V, `所与の値$ ］への~accessを有することになる。 ◎ Note: When defining getter steps, you implicitly have access to this. When defining setter steps, you implicitly have access to this and the given value.

`属性$の`識別子$は、［ 同じ`~ifc$上に定義される別の`~ifc~mb$の識別子 ］と同じになってはナラナイ。 静的~属性の識別子は、 `prototype^l になってはナラナイ。 ◎ The identifier of an attribute must not be the same as the identifier of another interface member defined on the same interface. The identifier of a static attribute must not be “prototype”.

属性の型は、 `attribute^sym ~keywordの後に現れる型 （ `Type$g に合致-） で与えられる。 `Type$g が［ `識別子$／ `?^sym が後続する識別子 ］である場合、 当の識別子は，次に挙げるいずれかを識別しなければナラナイ ⇒＃ `~ifc$／ `列挙$／ `~callback関数$／ `~callback~ifc$／ `~typedef$ ◎ The type of the attribute is given by the type (matching Type) that appears after the attribute keyword. If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function, callback interface or typedef.

属性の型は、 ~typedefの解決-後に，次に挙げる型, あるいはその`~nullable型$になってはナラナイ。 ◎ The type of the attribute, after resolving typedefs, must not be a nullable or non-nullable version of any of the following types:

• `連列~型$ ◎ a sequence type
• `非同期c連列~型$ ◎ an async sequence type
• `辞書~型$ ◎ a dictionary type
• `~record型$ ◎ a record type
• `共用体~型$のうち，その`平坦~化~mb型~群$に［ `~nullable$／非~nullable ］な［ 連列~型 ／ 辞書 ／ ~record【！区切り？】 ］（順不同）を含んでいるもの 【平坦~化~mb型~群は~nullableを含み得ないので，この “~nullable” の記述は不要では？】 ◎ a union type that has a nullable or non-nullable sequence type, dictionary, or record as one of its flattened member types

`attribute^sym ~keywordの前に `readonly^sym ~keywordが利用されている場合、 属性は `読専@ （ `read only^en, 読み取りのみ） になる。 ［ 読専な属性が定義されている~ifc ］を実装する~objにおいては、 その属性に対する代入は許容されないことになる。 代入が［ 単に言語において許容されないのか, 無視されるのか, あるいは例外が投出されるのか ］については、 言語束縛に特有になる。 ◎ The attribute is read only if the readonly keyword is used before the attribute keyword. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown.

interface `interface_identifier^i {
  readonly attribute `type^i `identifier^i;
};

`~promise型$である属性は、 `読専$でなければナラナイ。 加えて、 次の`拡張d属性$を有せない ⇒ `LegacyLenientSetter$x, `PutForwards$x, `Replaceable$x, `SameObject$x ◎ Attributes whose type is a promise type must be read only. Additionally, they cannot have any of the extended attributes [LegacyLenientSetter], [PutForwards], [Replaceable], or [SameObject].

`読専$でない`正則~属性$は、 先祖~ifcからその `取得子を継承する@ ように宣言できる。 これにより、 先祖~ifcの読専な属性を，派生~ifc上で~writableにできる。 属性は、 その宣言が `inherit^sym を伴うとき，`取得子を継承する$ものとされる。 その属性が取得子を継承する読専な属性は、［ 同じ識別子の属性が定義されている，先祖~ifc ］のうち，最も末端の~ifcに属する属性である。 【！readonlyとは限らない？】 取得子を［ 継承する側, される側 ］の属性の型は同じでなければナラナイ。 ◎ A regular attribute that is not read only can be declared to inherit its getter from an ancestor interface. This can be used to make a read only attribute in an ancestor interface be writable on a derived interface. An attribute inherits its getter if its declaration includes inherit in the declaration. The read only attribute from which the attribute inherits its getter is the attribute with the same identifier on the closest ancestor interface of the one on which the inheriting attribute is defined. The attribute whose getter is being inherited must be of the same type as the inheriting attribute.

注記： `inherit^sym が［ `読専$な属性／`静的~属性$ ］に現れることはない — それは、 文法により確保される。 ◎ Note: The grammar ensures that inherit does not appear on a read only attribute or a static attribute.

[Exposed=Window]
interface `Ancestor^i {
  readonly attribute `TheType^i `theIdentifier^i;
};

[Exposed=Window]
interface `Derived^i : `Ancestor^i {
  inherit attribute `TheType^i `theIdentifier^i;
};

`正則~属性$の宣言に `stringifier^sym ~keywordが利用されている場合、［ その~ifcを実装している~objを文字列~化するときは、 その属性の値になる ］ことを指示する。 詳細は、 `文字列化子＠#idl-stringifiers§を見よ。 ◎ When the stringifier keyword is used in a regular attribute declaration, it indicates that objects implementing the interface will be stringified to the value of the attribute. See § 2.5.5 Stringifiers for details.

interface `interface_identifier^i {
  stringifier attribute DOMString `identifier^i;
};

［ `正則~属性$／`静的~属性$ ］に適用-可能な拡張d属性は ⇒＃ `CrossOriginIsolated$x, `Exposed$x, `SameObject$x, `SecureContext$x ◎ The following extended attributes are applicable to regular and static attributes: [CrossOriginIsolated], [Exposed], [SameObject], and [SecureContext].

次に挙げる`拡張d属性$を適用-可能な`属性$は、 `正則~属性$に限られる ⇒＃ `LegacyLenientSetter$x, `LegacyLenientThis$x, `PutForwards$x, `Replaceable$x, `LegacyUnforgeable$x ◎ The following extended attributes are applicable only to regular attributes: [LegacyLenientSetter], [LegacyLenientThis], [PutForwards], [Replaceable], [LegacyUnforgeable].

[Exposed=Window]
interface Animal {

  /* 
単純な，どの文字列にも設定され得る属性。
◎
A simple attribute that can be set to any string value.
 */
  readonly attribute DOMString name;

  /* 
値を代入できる属性。
◎
An attribute whose value can be assigned to.
 */
  attribute unsigned short age;
};

[Exposed=Window]
interface Person : Animal {

  /* 
取得子の挙動を `Animal^T から継承する属性。
`Person^T の記述にて指定する必要はない。
◎
An attribute whose getter behavior is inherited from Animal, and need not be specified in the description of Person.
 */
  inherit attribute DOMString name;
};

2.5.3. 演算

`演算@ （ `operation^en ） （ `static^sym `RegularOperation$g, `stringifier^sym, `RegularOperation$g, `SpecialOperation$g いずれかに合致-） は、［ `~ifc~mb$／`~callback~ifc~mb$／`~ns~mb$ ］であり，当の［ `~ifc$／`~callback~ifc$／`~ns$ ］を実装している~obj上で呼出せる挙動を定義する。 ◎ An operation is an interface member, callback interface member or namespace member (matching static RegularOperation, stringifier, RegularOperation or SpecialOperation) that defines a behavior that can be invoked on objects implementing the interface.＼

演算には次の 3 種類がある： ◎ There are three kinds of operation:

• `正則~演算$は、 次を宣言するために利用される ⇒ 当の［ ~ifc／~ns ］を実装している~objは、 所与の`識別子$を伴う~methodを有する ◎ regular operations, which are those used to declare that objects implementing the interface will have a method with the given identifier

  interface `interface_identifier^i {
    `return_type^i `identifier^i(/* arguments... */);
  };
  

• `特殊~演算$は、 次を宣言するために利用される ⇒ ~objの~index法や文字列~化などの，当の~ifcを実装している~obj上の特殊な挙動 ◎ special operations, which are used to declare special behavior on objects implementing the interface, such as object indexing and stringification

  interface `interface_identifier^i {
    /* special_keyword */ `return_type^i `identifier^i(/* arguments... */);
    /* special_keyword */ `return_type^i (/* arguments... */);
  };
  

• `静的~演算$は、 次を宣言するために利用される ⇒ 当の~ifcを実装している特定0の~objには結付けられない演算 ◎ static operations, which are used to declare operations that are not associated with a particular object implementing the interface

  interface `interface_identifier^i {
    static `return_type^i `identifier^i(/* arguments... */);
  };
  

演算のうち，［ 識別子を有する ］~AND［ `static^sym ~keywordを伴わない ］ものは、 `正則~演算@ （ `regular operation^en ）を宣言する。 `特殊~keyword$ （すなわち、 `Special$g に合致する~keyword, または `stringifier^sym ） が宣言に利用されている演算は、 `特殊~演算$を宣言する。 演算を［ 正則~演算と特殊~演算を兼ねる ］ように宣言することもできる。 特殊~演算についての詳細は、 `特殊~演算＠#idl-special-operations§を見よ。 `正則~演算$には、 `~ifc~mb$の他にも，`~callback~ifc~mb$や`~ns~mb$もあることに注意。 ◎ If an operation has an identifier but no static keyword, then it declares a regular operation. If the operation has a special keyword used in its declaration (that is, any keyword matching Special, or the stringifier keyword), then it declares a special operation. A single operation can declare both a regular operation and a special operation; see § 2.5.6 Special operations for details on special operations. Note that in addition to being interface members, regular operations can also be callback interface members and namespace members.

識別子が無い演算は、 いずれかの特殊~keywordを利用して，`特殊~演算$として宣言されなければナラナイ。 ◎ If an operation has no identifier, then it must be declared to be a special operation using one of the special keywords.

`正則~演算$や`静的~演算$の識別子は、 同じ［ `~ifc$／`~callback~ifc$／`~ns$ ］上に定義される`定数$や`属性$の識別子と同じになってはナラナイ。 静的~演算の識別子は `prototype^l になってはナラナイ。 ◎ The identifier of a regular operation or static operation must not be the same as the identifier of a constant or attribute defined on the same interface, callback interface or namespace. The identifier of a static operation must not be “prototype”.

注記： しかしながら，~ifc上では、 複数の演算の識別子を同じにすることはできる。 演算の多重定義は、 これにより指定される。 ◎ Note: The identifier can be the same as that of another operation on the interface, however. This is how operation overloading is specified.

注記： `静的~演算$の`識別子$は、 同じ`~ifc$上に定義される`正則~演算$の識別子と同じにすることもできる。 ◎ Note: The identifier of a static operation can be the same as the identifier of a regular operation defined on the same interface..

演算の `返り値~型@ （ `return type^en ） （ `Type$g に合致-） は、 省略可能な［ 演算の`識別子$ ］の前に現れる型で与えられる。 返り値~型が： ◎ The return type of the operation is given by the type (matching Type) that appears before the operation’s optional identifier. If the return type＼

• `?^sym が後続する`識別子$である場合、 当の識別子は，次に挙げるいずれかを識別しなければナラナイ ⇒＃ `~ifc$／ `辞書$／ `列挙$／ `~callback関数$／ `~callback~ifc$／ `~typedef$ ◎ is an identifier followed by ?, then the identifier must identify an interface, dictionary, enumeration, callback function, callback interface or typedef.
• 【 `?^sym が後続しない`識別子$である場合については、 何も指定されていない。 】

演算の引数たち （ `ArgumentList$g に合致-） は、 当の宣言~内の丸括弧の合間にて与えられる。 各~引数は、［ 型 （ `Type$g に合致-）, それに後続する`識別子$ （ `ArgumentName$g に合致-） ］として指定される。 ◎ An operation’s arguments (matching ArgumentList) are given between the parentheses in the declaration. Each individual argument is specified as a type (matching Type) followed by an identifier (matching ArgumentName).

注記： 表出力を得るため、 演算~引数の識別子には， `ArgumentNameKeyword$g 記号に合致する~keywordも — ~escapeを要することなく — 指定できる。 【！＊】 ◎ Note: For expressiveness, the identifier of an operation argument can also be specified as one of the keywords matching the ArgumentNameKeyword symbol without needing to escape it.

演算~引数の型が： ◎ If the Type of an operation argument is＼

• `?^sym が後続する`識別子$である場合、 当の識別子は，次に挙げるいずれかを識別しなければナラナイ ⇒＃ `~ifc$ ／ `列挙$ ／ `~callback関数$ ／ `~callback~ifc$ ／ `~typedef$ ◎ an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function, callback interface, or typedef.＼
• `?^sym が後続しない`識別子$である場合、 当の識別子は，次に挙げるいずれかを識別しなければナラナイ ⇒＃ `辞書$ ／ 前項に挙げたいずれかの`定義$ ◎ If the operation argument type is an identifier not followed by ?, then the identifier must identify any one of those definitions or a dictionary.

演算~引数の型が`~typedef$の解決-後に`~nullable型$になる場合、 その`内縁~型$は`辞書~型$になってはナラナイ。 ◎ If the operation argument type, after resolving typedefs, is a nullable type, its inner type must not be a dictionary type.

interface `interface_identifier^i {
  `return_type^i `identifier^i(`type^i `identifier^i, `type^i `identifier^i /* , ... */);
};

各~引数の識別子は、 同じ演算~宣言~内の他の引数の識別子と同じになってはナラナイ。 ◎ The identifier of each argument must not be the same as the identifier of another argument in the same operation declaration.

各~引数には、 `拡張d属性$たちが成す~list （ `ExtendedAttributeList$g に合致-） を前置できる — それらは、［ 当の引数として渡された値が，言語束縛において どう取扱われるか ］を制御する。 ◎ Each argument can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how a value passed as the argument will be handled in language bindings.

interface `interface_identifier^i {
  `return_type^i `identifier^i([`extended_attributes^mk] `type^i `identifier^i, [`extended_attributes^mk] `type^i `identifier^i /* , ... */);
};

[Exposed=Window]
interface Dimensions {
  attribute unsigned long width;
  attribute unsigned long height;
};

[Exposed=Window]
interface Button {

  /* 
引数をとらず, `boolean^T を返す演算
◎
An operation that takes no arguments and returns a boolean.
 */
  boolean isMouseOver();

  /* 
多重定義された演算。
◎
Overloaded operations.
 */
  undefined setDimensions(Dimensions %size);
  undefined setDimensions(unsigned long %width, unsigned long %height);
};

［ 演算／`構築子~演算$ ］を成す最後の引数の型の直後に `…^sym ~tokenが利用された場合、 当の演算は `可変個的な@ もの（ `variadic^en ）と見なされ， 最後の引数を指して `可変個~引数@ という†。 そのように宣言された演算は： ◎ An operation or constructor operation is considered to be variadic if the final argument uses the … token just after the argument type.＼

【† この用語は、 他から参照し易くするため，この訳にて導入したもの。 】

• `可変個~引数$の後に，任意~個数の引数を伴って呼出せることを指示し、 それらの余分な暗黙な正式な引数の型は，`可変個~引数$と同じ型と見なされる。 ◎ Declaring an operation to be variadic indicates that the operation can be invoked with any number of arguments after that final argument. Those extra implied formal arguments are of the same type as the final explicit argument in the operation declaration.＼
• 呼出すときには、 `可変個~引数$も省略できる。 ◎ The final argument can also be omitted when invoking the operation.＼
• `可変個~引数$以外の引数は、 `…^sym ~tokenを伴って宣言してはナラナイ。 ◎ An argument must not be declared with the … token unless it is the final argument in the operation’s argument list.

interface `interface_identifier^i {
  `return_type^i `identifier^i(`type^i`...^em `identifier^i);
  `return_type^i `identifier^i(`type^i `identifier^i, `type^i`...^em `identifier^i);
};

【！原文誤＊`引数~listを引数にとる$】 `有名~引数~listを引数にとる$`拡張d属性$ （この仕様に定義される `LegacyFactoryFunction$x ）, および`~callback関数$も、 その引数~listに `…^sym ~tokenが利用されたならば，`可変個的な$ものと見なされる。 ◎ Extended attributes that take an argument list ([LegacyFactoryFunction], of those defined in this specification) and callback functions are also considered to be variadic when the … token is used in their argument lists.

【 以下の記述における可変個的な演算の “演算” には、 これらの（構築子を与える）拡張d属性や~callbackも含まれる。 】

[Exposed=Window]
interface IntegerSet {
  readonly attribute unsigned long cardinality;

  undefined union(long... %ints);
  undefined intersection(long... %ints);
};

var %s = getIntegerSet();  /* 
`IntegerSet^T の~instanceを得する。
◎
Obtain an instance of IntegerSet.
 */

%s.union();                /* 
`ints^l に対応する引数を~~省略。
◎
Passing no arguments corresponding to 'ints'.
 */
%s.union(1, 4, 7);         /* 
`ints^l に対応する 3 個の引数を渡す。
◎
Passing three arguments corresponding to 'ints'.
 */

`optional^sym ~keywordを伴って宣言された引数は、 `随意~引数@ （ `optional argument^en ）であるものと見なされる。 `可変個的な$演算の`可変個~引数$も随意~引数と見なされる。 随意として宣言された引数は、［ 演算を呼出すときに，その値を省略できる ］ことを指示する。 `可変個~引数$は、 明示的に随意として宣言してはナラナイ。 ◎ An argument is considered to be an optional argument if it is declared with the optional keyword. The final argument of a variadic operation is also considered to be an optional argument. Declaring an argument to be optional indicates that the argument value can be omitted when the operation is invoked. The final argument in an operation must not explicitly be declared to be optional if the operation is variadic.

interface `interface_identifier^i {
  `return_type^i `identifier^i(`type^i `identifier^i, optional `type^i `identifier^i);
};

随意~引数には `既定~値@ （ `default value^en ）を指定できる。 引数の識別子に `003D^U1 と値 （ `DefaultValue$g に合致-） が後続している場合、 その値がその随意~引数の`既定~値$を与える。 ただし，`可変個的な$演算の`可変個~引数$には、 既定~値を指定してはナラナイ。 既定~値は、 対応する引数が省略されて演算が~callされたときに，その引数がとる値と見做される。 ◎ Optional arguments can also have a default value specified. If the argument’s identifier is followed by a U+003D (=) and a value (matching DefaultValue), then that gives the optional argument its default value. The implicitly optional final argument of a variadic operation must not have a default value specified. The default value is the value to be assumed when the operation is called with the corresponding argument omitted.

interface `interface_identifier^i {
  `return_type^i `identifier^i(`type^i `identifier^i, optional `type^i `identifier^i = "`value^i");
};

`boolean$T 型の引数には、 `既定~値$として `true^V を利用しないことが強く示唆される。 さもなければ、 `undefined^jv に既定の変換（すなわち， `false^V ）が利用されると期待する作者たちを惑わすことになるので。 `API-DESIGN-PRINCIPLES$r ◎ It is strongly suggested not to use a default value of true for boolean-typed arguments, as this can be confusing for authors who might otherwise expect the default conversion of undefined to be used (i.e., false). [API-DESIGN-PRINCIPLES]

~AND↓ を満たす引数は、 随意として指定した上で，既定~値も供さなければナラナイ。 ◎ ↓

• 引数の型は、 次を満たす ⇒ ［ `辞書~型$である ］~OR［ `共用体~型$であって，その`平坦~化~mb型~群$に ある`辞書~型$を含んでいる ］ ◎ If the type of an argument is a dictionary type or a union type that has a dictionary type as one of its flattened member types, and＼
• 前項の辞書~型, その先祖たちには、 `要求され$diCる`辞書~mb$は無い ◎ that dictionary type and its ancestors have no required members, and＼
• ［ 引数は最後の引数である ］~OR［ 引数に後続するどの引数も`随意~引数$である ］ ◎ the argument is either the final argument or is followed only by optional arguments,＼ then the argument must be specified as optional and have a default value provided.

【 そのような辞書~引数が省略された場合、 その各~mbは，`既定~値$diCが指定されていれば それをとるものと扱われることになる。 】

注記： これは、［ 作者が辞書の既定~値のみの利用を望むときでも，空な辞書~値を渡さずに済む ］ような~APIの設計を促すためにある。 ◎ This is to encourage API designs that do not require authors to pass an empty dictionary value when they wish only to use the dictionary’s default values.

注記： 引数に供される既定~値は，通例的には `{}^sym になるが、［ 引数が`共用体~型$であって，その`平坦~化~mb型~群$が`辞書~型$を含んでいる事例 ］では，［ 共用体の他の何らかの~mbを初期化する既定~値 ］を供することもできる。 ◎ Usually the default value provided will be {}, but in the case of a union type that has a dictionary type as one of its flattened member types a default value could be provided that initializes some other member of the union.

`既定~値$に［ `ConstValue$g ／ `null^sym ］が利用された場合、 `定数$に対するときと同じ仕方で解釈される。 ◎ When a boolean literal token (true or false), the null token, an integer token, a decimal token or one of the three special floating point literal values (Infinity, -Infinity or NaN) is used as the default value, it is interpreted in the same way as for a constant.

`undefined^sym ~tokenが`既定~値$として利用されたときは、 その値は，~IDL `undefined$T 値になる。 ◎ When the undefined token is used as the default value, the value is the IDL undefined value.

`随意~引数$の型が`列挙$である場合、 その`既定~値$に指定される値は，その列挙を成すいずれかの`列挙~値$でなければナラナイ。 ◎ If the type of the optional argument is an enumeration, then its default value if specified must be one of the enumeration’s values.

`連列~型$（`~nullable$も含む）の随意~引数の既定~値には、［ 2 個の~tokenが成す値 `[]^sym ］を利用して，［ その型と同じ型の空~連列~値 ］を表現する値も指定できる。 この既定~値の型は、 次のいずれかでなければナラナイ ⇒＃ `連列~型$ ／ `~nullable$であって その`内縁~型$は`連列~型$であるもの ／ `共用体~型$または`~nullable$なそれであって その`平坦~化~mb型~群$は`連列~型$を含むもの ◎ Optional argument default values can also be specified using the two token value [], which represents an empty sequence value. The type of this value is the same as the type of the optional argument it is being used as the default value of. That type must be a sequence type, a nullable type whose inner type is a sequence type or a union type or nullable union type that has a sequence type in its flattened member types.

`辞書~型$の随意~引数の既定~値には、［ 2 個の~tokenが成す値 `{}^sym ］を利用して，［ その型と同じ型の辞書~値であって，既定に【各~mbが既定~値に】初期化されるもの 【！(as if from ES null or an object with no properties)】 ］を表現する値も指定できる。 この既定~値の型は、 次のいずれかでなければナラナイ ⇒＃ `辞書~型$ ／ `共用体~型$であって その`平坦~化~mb型~群$は`辞書~型$を含むもの ◎ Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value. The type of this value is the same as the type of the optional argument it is being used as the default value of. That type must be a dictionary type, or a union type that has a dictionary type in its flattened member types.

[Exposed=Window]
interface ColorCreator {
  object createColor(double %v1, double %v2, double %v3, optional double %alpha);
};

[Exposed=Window]
interface ColorCreator {
  object createColor(double %v1, double %v2, double %v3);
  object createColor(double %v1, double %v2, double %v3, double %alpha);
};

dictionary LookupOptions {
  boolean caseSensitive = false;
};

[Exposed=Window]
interface AddressBook {
  boolean hasAddressForName(USVString %name, optional LookupOptions %options = {});
};

演算に適用-可能な拡張d属性は ⇒＃ `CrossOriginIsolated$x, `Default$x, `Exposed$x, `LegacyUnforgeable$x `NewObject$x, `SecureContext$x, ◎ The following extended attributes are applicable to operations: [CrossOriginIsolated], [Default], [Exposed], [LegacyUnforgeable], [NewObject], and [SecureContext].

演算 %演算 の `~method手続き@ （ `method steps^en ）は、 次の形を成す~textを利用して導入されるベキである ⇒ “%演算(%arg1, %arg2, ...) ~method手続きは…” （［ ~listまたは~inline ］による記述が後続する） ◎ The method steps of an operation operation should be introduced using text of the form “The operation(arg1, arg2, …) method steps are:” followed by a list, or “The operation(arg1, arg2, …) method steps are to” followed by an inline description.

注記： `~method手続き$を定義するときは、 暗黙的に `this$V への~accessを有することになる。 ◎ Note: When defining method steps, you implicitly have access to this.

【 値を返さないように定義される`~method手続き$は、 暗黙的に， `undefined$T 型の値を返すものと見なされる。 】

[Exposed=Window]
interface Transaction {
  readonly attribute DOMString from;
  readonly attribute DOMString to;
  readonly attribute double amount;
  readonly attribute DOMString description;
  readonly attribute unsigned long number;
  TransactionJSON toJSON();
};

dictionary TransactionJSON {
  Account from;
  Account to;
  double amount;
  DOMString description;
};

/* 
`Transaction^T の~instanceを取得する：
◎
Get an instance of Transaction.
 */
var %txn = getTransaction();

/* 
次の様な~objに評価される：
◎
Evaluates to an object like this:
 */
   {
     from: "Bob",
     to: "Alice",
     amount: 50,
     description: "books"
   }
*/
%txn.toJSON();

/* 
次の様な文字列に評価される：
◎
Evaluates to a string like this:
 */
   '{"from":"Bob","to":"Alice","amount":50,"description":"books"}'
*/
JSON.stringify(%txn);

2.5.4. 構築子~演算

`~ifc$の~mbとして`構築子~演算$ （ `Constructor$g に合致-） がある場合、［ `構築子$を利用して`~ifc$を`実装-$する~objを作成する ］ことがアリになることを指示する。 ◎ If an interface has a constructor operation member (matching Constructor), it indicates that it is possible to create objects that implement the interface using a constructor.

所与の`~ifc$上に複数の`構築子~演算$が現れてもヨイ。 `~ifc$の各`構築子~演算$ごとに，指定された引数を渡して~instanceを構築するよう試みる仕方があることになる。 ◎ Multiple constructor operations may appear on a given interface. For each constructor operation on the interface, there will be a way to attempt to construct an instance by passing the specified arguments.

名前 %Example の~ifcの~mbである`構築子~演算$の `構築子~手続き@ （ `constructor steps^en ）は、 次の形を成す~textを利用して導入されるベキである ⇒ “new %Example(%arg1, %arg2, ...) 構築子~手続きは…” （［ ~listまたは~inline ］による記述が後続する） ◎ The constructor steps of a constructor operation that is a member of an interface named interface should be introduced using text of the form “The new interface(arg1, arg2, …) constructor steps are:” followed by a list, or “The new interface(arg1, arg2, …) constructor steps are to” followed by an inline description.

`構築子~手続き$は、 次のいずれかをしなければナラナイ ⇒＃ 何もしない／ `this$V として渡された値を初期化する／ 例外を投出する ◎ The constructor steps must do nothing, initialize the value passed as this, or throw an exception.

【 構築子~手続きは，一般に、 当の~ifcの~instanceの作成まで受持つことはなく，初期化のみを行う — `~instanceを作成する＠~WEBIDLjs#new$ためには、 それが属する`~realm$（それは、構築子の引数には無い）を指定する必要があるので （多くの事例では，`現在の~realm$がその用を成すが、 明示的に指定する必要がある事例も多々ある）。 】

当の構築子が `this$V を初期化しない場合、 次のように書ける ⇒ “new Example(%init) 構築子~手続きは何もしない” ◎ If the constructor does not initialize this, one can write “The new Example(init) constructor steps are to do nothing.”

`構築子~演算$がどう実装されるかの詳細は、 `~ifc~obj＠~WEBIDLjs#interface-object§を見よ。 ◎ See § 3.7.1 Interface object for details on how a constructor operation is to be implemented.

[Exposed=Window]
interface NodeList {
  Node item(unsigned long index);
  readonly attribute unsigned long length;
};

[Exposed=Window]
interface Circle {
  constructor();
  constructor(double radius);
  attribute double r;
  attribute double cx;
  attribute double cy;
  readonly attribute double circumference;
};

var %x = new Circle();      /* 
これは，引数なしの構築子を利用して
`Circle^T ~ifcを実装する~platform~objへの参照を作成する。
◎
This uses the zero-argument constructor to create a reference to a platform object that implements the Circle interface.
 */

var %y = new Circle(1.25);  /* 
今度は 1 個の引数をとる構築子を利用して
`Circle^T ~objを作成する。
◎
This also creates a Circle object, this time using the one-argument constructor.
 */

var %z = new NodeList();    /* 
構築子が宣言されていないので `TypeError^jE が投出されることになる。
◎
This would throw a TypeError, since no constructor is declared.
 */

2.5.5. 文字列化子

`~ifc$に `文字列化子@ （ `stringifier^en ）がある場合、［ 当の~ifcを実装する~objは、 文字列への既定でない変換を有する ］ことを指示する。 文字列化子は、 `stringifier^sym ~keywordを利用して指定できる — それは、 それのみで利用されたときは，文字列化子~演算を作成する。 ◎ When an interface has a stringifier, it indicates that objects that implement the interface have a non-default conversion to a string. Stringifiers can be specified using a stringifier keyword, which creates a stringifier operation when used alone.

interface `interface_identifier^i {
  stringifier;
};

そのような~ifcに付随する注釈文は、 当の~ifcの `文字列~化の挙動@ （ `stringification behavior^en ）を定義しなければナラナイ。 ◎ Prose accompanying the interface must define the stringification behavior of the interface.

`stringifier^sym ~keywordは、 `属性$に置くこともできる。 この場合、 その属性の値が，~objから文字列への変換-を与える。 `stringifier^sym ~keywordは、［ `静的~属性$ ／［ `DOMString$T／`USVString$T ］として宣言されていない属性 ］に置かれてはナラナイ。 ◎ The stringifier keyword can also be placed on an attribute. In this case, the string to convert the object to is the value of the attribute. The stringifier keyword must not be placed on an attribute unless it is declared to be of type DOMString or USVString. It also must not be placed on a static attribute.

interface `interface_identifier^i {
  stringifier attribute DOMString `identifier^i;
};

所与の`~ifc$上に存在する文字列化子は、 高々 1 個まででなければナラナイ。 ◎ On a given interface, there must exist at most one stringifier.

[Exposed=Window]
interface Student {
  constructor();
  attribute unsigned long id;
  stringifier attribute DOMString name;
};

var %s = new Student();
%s.id = 12345678;
%s.name = '周杰倫';

var %挨拶 = 'こんにちは、 ' + %s + ' さん。';
    /* 
`こんにちは、 周杰倫 さん。^l になる。
◎
Now greeting == 'Hello, 周杰倫!'.
 */

[Exposed=Window]
interface Student {
  constructor();
  attribute unsigned long id;
  attribute DOMString? familyName;
  attribute DOMString givenName;

  stringifier;
};

var %s = new Student();
%s.id = 12345679;
%s.familyName = 'Smithee';
%s.givenName = 'Alan';

var %挨拶 = 'こんにちは、 ' + %s + ' さん。';
    /* 
`こんにちは、 Alan Smithee さん^l になる。
◎
Now greeting == 'Hi Alan Smithee'.
 */

2.5.6. 特殊~演算

`特殊~演算@ （ `special operation^en ）は、［ その特殊~演算~宣言が現れる~ifcを実装する~obj ］上の［ 一定の種類の特殊な挙動 ］の宣言である。 `特殊~演算$は，演算~宣言において `特殊~keyword@ （ `special keyword^en ）を利用して宣言される。 ◎ A special operation is a declaration of a certain kind of special behavior on objects implementing the interface on which the special operation declarations appear. Special operations are declared by using a special keyword in an operation declaration.

`特殊~演算$には、 次の表tに挙げる 3 種類がある。 表tには、 各~特殊~演算に対し， それを宣言するために利用される特殊~keyword, および 演算の目的も示す： ◎ There are three kinds of special operations. The table below indicates for a given kind of special operation what special keyword is used to declare it and what the purpose of the special operation is:

すべての言語束縛が、 これら 3【！four】 種類の［ ~objの特殊な挙動 ］すべてを~supportするわけではない。 `特殊~演算$が，識別子を伴わない演算を利用して宣言された場合、 その特定0の種類の特殊~演算を~supportしない言語束縛においては，単にその機能性が存在しないことになる。 ◎ Not all language bindings support all of the four kinds of special object behavior. When special operations are declared using operations with no identifier, then in language bindings that do not support the particular kind of special operations there simply will not be such functionality.

[Exposed=Window]
interface Dictionary {
  readonly attribute unsigned long propertyCount;

  getter double (DOMString %propertyName);
  setter undefined (DOMString %propertyName, double %propertyValue);
};

`特殊~演算$を`識別子$を伴わせて定義することは、 その宣言から識別子を伴わない特殊~演算を分離することと，等価である。 この書き方は、 ~ifcの演算を成す`~method手続き$を単純~化するために許容されている。 ◎ Defining a special operation with an identifier is equivalent to separating the special operation out into its own declaration without an identifier. This approach is allowed to simplify method steps of an interface’s operations.

[Exposed=Window]
interface Dictionary {
  readonly attribute unsigned long propertyCount;

  getter double getProperty(DOMString %propertyName);
  setter undefined setProperty(DOMString %propertyName, double %propertyValue);
};

[Exposed=Window]
interface Dictionary {
  readonly attribute unsigned long propertyCount;

  double getProperty(DOMString %propertyName);
  undefined setProperty(DOMString %propertyName, double %propertyValue);

  getter double (DOMString %propertyName);
  setter undefined (DOMString %propertyName, double %propertyValue);
};

1 つの演算に同じ`特殊~keyword$が複数~回 現れてはナラナイ。 ◎ A given special keyword must not appear twice on an operation.

［ 取得子, 設定子, 削除子 ］は、 次に挙げる 2 種の系統に分類される： ◎ Getters and setters come in two varieties:＼

• `有名~prop取得子@ （ `named property getter^en ）, `有名~prop設定子@ （ `named property setter^en ）, `有名~prop削除子@ （ `named property deleter^en ） と呼ばれる，~prop名として `DOMString$T をとるもの。 ◎ ones that take a DOMString as a property name, known as named property getters and named property setters, and＼
• `有index~prop取得子@ （ `indexed property getter^en ）, `有index~prop設定子@ （ `indexed property setter^en ） と呼ばれる，~prop~indexとして `unsigned long$T をとるもの — 有index~propには，`削除子は無い^em。 ◎ ones that take an unsigned long as a property index, known as indexed property getters and indexed property setters. There is only one variety of deleter: named property deleters.＼

詳細は、 `有index~prop＠#idl-indexed-properties§, `有名~prop＠#idl-named-properties§ を見よ。 ◎ See § 2.5.6.1 Indexed properties and § 2.5.6.2 Named properties for details.

所与の`~ifc$上に存在する［ `削除子$ および, 各~系統の［ `取得子$, `設定子$ ］］は、 それぞれ，高々 1 個まででなければナラナイ。 ◎ On a given interface, there must exist at most one named property deleter, and at most one of each variety of getter and setter.

~ifcが［ いずれかの系統の`設定子$, あるいは`有名~prop削除子$ ］を有する場合、 同じ系統の`取得子$も有さなければナラナイ。 ◎ If an interface has a setter of a given variety, then it must also have a getter of that variety. If it has a named property deleter, then it must also have a named property getter.

演算を利用して宣言される`特殊~演算$は，［ `可変個的な$ ／ `随意~引数$をとる ］ようにしてはナラナイ。 ◎ Special operations declared using operations must not be variadic nor have any optional arguments.

~objが，所与の`特殊~演算$を定義する複数の`~ifc$を実装する場合、 その演算に対し，どの特殊~演算が呼出されるかは 未定義である。 ◎ If an object implements more than one interface that defines a given special operation, then it is undefined which (if any) special operation is invoked for that operation.

interface `interface_identifier^i {
  getter `type^i `identifier^i(unsigned long `identifier^i);
  setter `type^i `identifier^i(unsigned long `identifier^i, `type^i `identifier^i);

  getter `type^i (unsigned long `identifier^i);
  setter `type^i (unsigned long `identifier^i, `type^i `identifier^i);
};

[Exposed=Window]
interface A {
  getter DOMString toWord(unsigned long %index);
};

var %a = getA();

%a.toWord(0);  /* 
`zero^l  に評価される。
◎
Evaluates to "zero".
 */
%a[0];         /* 
これも `zero^l に評価される。
◎
Also evaluates to "zero".
 */

%a.toWord(5);  /* 
`five^l に評価される。
◎
Evaluates to "five".
 */
%a[5];         /* 
~prop `5^l は存在しないので `undefined^jv に評価される。
◎
Evaluates to undefined, since there is no property "5".
 */

[Exposed=Window]
interface OrderedMap {
  readonly attribute unsigned long size;

  getter any getByIndex(unsigned long %index);
  setter undefined setByIndex(unsigned long %index, any %value);

  getter any get(DOMString %name);
  setter undefined set(DOMString %name, any %value);
};

/* 
%map は `OrderedMap^T ~ifcを実装する旧来の~platform~objであるとする：
◎
Assume map is a legacy platform object implementing the OrderedMap interface.
 */
var %map = getOrderedMap();
var %x, %y;

%x = %map[0];       /* 
`map.size^c 【！map.length】~GT 0 ならば、
これは
`x = map.getByIndex(0)^c
と等価になる
（名前 `0^l の~propが %map 上に置かれるので）。
他の場合、
%map 上には名前 `0^l の~propは無いので，
%x は `undefined^jv に設定されることになる。
◎
If map.length > 0, then this is equivalent to:

  x = map.getByIndex(0)

since a property named "0" will have been placed on map.
Otherwise, x will be set to undefined, since there will be
no property named "0" on map.
 */

%map[1] = false;   /* 
これは、
`map.setByIndex(1, false)^c
と等価な動作になる。
◎
This will do the equivalent of:

  map.setByIndex(1, false)
 */

%y = %map.apple;    /* 
名前 `apple^l の有名~propが存在する場合、
%map 上には名前 `apple^l の~propが在るので，
`y = map.get('apple')^c
と等価な動作になる。
他の場合、
%map 上には名前 `apple^l の~propは無いので，
%y は `undefined^jv に設定されることになる。
◎
If there exists a named property named "apple", then this
will be equivalent to:

  y = map.get('apple')

since a property named "apple" will have been placed on
map.  Otherwise, y will be set to undefined, since there
will be no property named "apple" on map.
 */

%map.berry = 123;  /* 
これは、
`map.set('berry', 123)^c
と等価な動作になる。
◎
This will do the equivalent of:

  map.set('berry', 123)
 */

delete %map.cake;  /* 
有名~prop `cake^l が存在するならば、
`cake^jp ~propは削除され，
`map.remove("cake")^c
と等価な動作になる。
◎
If a named property named "cake" exists, then the "cake"
property will be deleted, and then the equivalent to the
following will be performed:

	  map.remove("cake")
 */

interface `interface_identifier^i {
  getter `type^i `identifier^i(DOMString `identifier^i);
  setter `type^i `identifier^i(DOMString `identifier^i, `type^i `identifier^i);
  deleter `type^i `identifier^i(DOMString `identifier^i);

  getter `type^i (DOMString `identifier^i);
  setter `type^i (DOMString `identifier^i, `type^i `identifier^i);
  deleter `type^i (DOMString `identifier^i);
};

2.5.7. 静的~属性と静的~演算

［ `静的~属性@ （ `static attribute^en ）／ `静的~演算@ （ `static operation^en ） ］は、 それを宣言した`~ifc$の特定0の~instanceには結付けられないものであり、 代わりに，当の~ifc自身に結付けられる。 ［ 静的~属性／静的~演算 ］は、 自身の宣言の中で `static^sym ~keywordを利用して宣言される。 ◎ Static attributes and static operations are ones that are not associated with a particular instance of the interface on which it is declared, and is instead associated with the interface itself. Static attributes and operations are declared by using the static keyword in their declarations.

［ 静的~演算を呼出す／ 静的~属性を取得する／ 静的~属性を設定する ］ことが，~ifcの~instanceへの参照を通してアリかどうかは、 言語束縛に特有になる。 ◎ It is language binding specific whether it is possible to invoke a static operation or get or set a static attribute through a reference to an instance of the interface.

[Exposed=Window]
interface Point { /* ... */ };

[Exposed=Window]
interface Circle {
  attribute double cx;
  attribute double cy;
  attribute double radius;

  static readonly attribute long triangulationCount;
  static Point triangulate(Circle %c1, Circle %c2, Circle %c3);
};

var %circles = getCircles();        /* 
`Circle^T ~objの `Array^jt
◎
an Array of Circle objects
 */

typeof Circle.triangulate;         /*  */
typeof Circle.triangulationCount;  /* 
`number^l に評価される。
◎
Evaluates to "number"
 */
Circle.prototype.triangulate;      /* 
`undefined^jv に評価される。
◎
Evaluates to undefined
 */
Circle.prototype.triangulationCount;  /* 
これも `undefined^jv に評価される。
◎
Also evaluates to undefined
 */
%circles[0].triangulate;            /* 
これも。
◎
As does this
 */
%circles[0].triangulationCount;     /* 
これも。
◎
And this
 */

/* 
静的~演算の~call：
◎
Call the static operation
 */
var %triangulationPoint = Circle.triangulate(%circles[0], %circles[1], %circles[2]);

/* 
`triangulate^M を呼んだ回数を調べる：
◎
Find out how many triangulations we have done
 */
window.alert(Circle.triangulationCount);

2.5.8. 多重定義

`~ifc$上に定義される［ 複数の`正則~演算$／複数の`静的~演算$ ］が同じ`識別子$を有する場合、 それらの演算は `多重定義@ （ `overload^en ）されているという。 当の~ifcを実装する~obj上で［ それらいずれかの演算を呼出すために，多重定義された演算の識別子が利用された ］とき，どの演算が実際に呼出されるかは、 演算に渡された ( 引数の個数, それらの各 型 ) により決定される。 `構築子~演算$も多重定義され得る。 多重定義された［ 演算／構築子 ］がとれるものと指定される引数には，一定の制約があり、 これらの制約を記述するため，`有効-多重定義~集合$の観念が利用される。 ◎ If a regular operation or static operation defined on an interface has an identifier that is the same as the identifier of another operation on that interface of the same kind (regular or static), then the operation is said to be overloaded. When the identifier of an overloaded operation is used to invoke one of the operations on an object that implements the interface, the number and types of the arguments passed to the operation determine which of the overloaded operations is actually invoked. Constructor operations can be overloaded too. There are some restrictions on the arguments that overloaded operations and constructors can be specified to take, and in order to describe these restrictions, the notion of an effective overload set is used.

多重定義された`演算$たちが成す集合は、 次を満たさなければナラナイ ⇒ ［ どの`演算$も`返り値~型$は`~promise型$でない ］~OR［ どの`演算$も`返り値~型$は`~promise型$である ］ ◎ A set of overloaded operations must either: • contain no operations whose return type is a promise type; • only contain operations whose return type is a promise type.

`演算$は、 複数の［ `~ifc$, `部分的な~ifc$, `~ifc~mixin$, `部分的な~ifc~mixin$ ］にまたがって多重定義してはナラナイ。 ◎ Operations must not be overloaded across interface, partial interface, interface mixin, and partial interface mixin definitions.

[Exposed=Window]
interface A {
  undefined f();
};

partial interface A {
  undefined f(double %x);
  undefined g();
};

partial interface A {
  undefined g(DOMString %x);
};

`正則~演算$ ◎ For regular operations

`静的~演算$ ◎ For static operations

`演算$が見出される`~ifc$, および 演算の`識別子$ ◎ the interface on which the operations are to be found ◎ the identifier of the operations ◎ the number of arguments to be passed

`構築子~演算$ ◎ For constructors

`構築子~演算$が見出される`~ifc$ ◎ the interface on which the constructor operations are to be found ◎ the number of arguments to be passed

`旧来の~factory関数$ ◎ For legacy factory functions

`LegacyFactoryFunction$x `拡張d属性$が見出される`~ifc$, および 当の旧来の~factory関数の`識別子$ ◎ the interface on which the [LegacyFactoryFunction] extended attributes are to be found ◎ the identifier of the legacy factory function ◎ the number of arguments to be passed

`有効-多重定義~集合$は、 ~ifc上に多重定義された`関数~類$たちに多義性があるかどうかを — 他と伴に — 決定するために利用される。 ◎ An effective overload set is used, among other things, to determine whether there are ambiguities in the overloaded operations and constructors specified on an interface.

`有効-多重定義~集合$は、 `有順序~集合$である — それを成す各`~item$は、 次に挙げる`~item$sctからなる`~tuple$である： ◎ The items of an effective overload set are tuples of the form (callable, type list, optionality list) whose items are described below:

`~callable@oL

`関数~類$の~~種別に応じて：

`正則~演算$

`静的~演算$

`構築子~演算$

【同じ識別子を共有する】いずれかの`演算$

`旧来の~factory関数$

【同じ識別子を共有する】いずれかの`拡張d属性$

◎ A callable is an operation if the effective overload set is for regular operations, static operations, or constructor operations; and it is an extended attribute if the effective overload set is for legacy factory functions.

`型~list@oL

`~callable$oLの各~引数に指定された~IDL型たちが成す`~list$ ◎ A type list is a list of IDL types.

`省略可否~list@oL

`省略可否 値$たちが成す`~list$ ◎ An optionality list is a list of＼

各 `省略可否 値@ （ `optionality value^en ） にアリな値は、 次に挙げるいずれかであり， 所与の~indexに位置する引数について指示する ⇒＃ `必須^C — 引数は省略できない ／ `省略可^C — `随意~引数$である ／ `可変個^C — `可変個~引数$である ◎ three possible optionality values – “required”, “optional” or “variadic” – indicating whether the argument at a given index was declared as being optional or corresponds to a variadic argument.

各`~tuple$は、 当の`関数~類$に対する［ 所与の型の引数~値たちが成す~listを伴う呼出n ］として許容-可能なものを表現する。 ［ `随意~引数$／ `可変個的な$`関数~類$（すなわち，演算または構築子） ］の利用に因り、 `有効-多重定義~集合$内には， 同じ種類の`関数~類$を識別する複数個の~itemが存在し得る。 ◎ Each tuple represents an allowable invocation of the operation, constructor, or callback function with an argument value list of the given types. Due to the use of optional arguments and variadic operations and constructors, there may be multiple items in an effective overload set identifying the same operation or constructor.

[Exposed=Window]
interface A {
  /* f1 */ undefined f(DOMString %a);
  /* f2 */ undefined f(Node %a, DOMString %b, double... %c);
  /* f3 */ undefined f();
  /* f4 */ undefined f(Event %a, DOMString %b, optional DOMString %c, double... %d);
};

«
  (f1, « DOMString »,                           « `必須^C »),
  (f2, « Node, DOMString »,                     « `必須^C, `必須^C »),
  (f2, « Node, DOMString, double »,             « `必須^C, `必須^C, `可変個^C »),
  (f2, « Node, DOMString, double, double »,     « `必須^C, `必須^C, `可変個^C, `可変個^C »),
  (f3, « »,                                     « »),
  (f4, « Event, DOMString »,                    « `必須^C, `必須^C »),
  (f4, « Event, DOMString, DOMString »,         « `必須^C, `必須^C, `省略可^C »),
  (f4, « Event, DOMString, DOMString, double », « `必須^C, `必須^C, `省略可^C, `可変個^C »)
»

所与の ( 負でない整数 %~size 【すなわち，引数~個数】, `有効-多重定義~集合$ %S ) に対し、 %T は %S を成す`~item$のうち［ その`型~list$oLの`~size$ ~EQ %~size ］を満たすものたちが成す集合とするとき， %T が複数個の~itemからなるならば： ◎ If there is more than one item in an effective overload set that has a given type list size,＼

• 次を満たす~index %i ~IN { 0 〜 %~size ~MINUS 1 } が存在しなければナラナイ ⇒ どの［ %A, %B ~IN %T ］に対しても，次が満たされる ⇒ ［ %A ~EQ %B ］~OR［ %A の`型~list$oL[ %i ], %B の`型~list$oL[ %i ] は`判別-可能$である ］ ◎ then for those items there must be an index i such that for each pair of items the types at index i are distinguishable.＼

• 前項の条件を満たす~indexのうち最小なものを， %~size に対する `判別~引数~index@ （ `distinguishing argument index^en ）という。 ◎ The lowest such index is termed the distinguishing argument index for the items of the effective overload set with the given type list size.

  %j を`判別~引数~index$とするとき、 どの［ %A, %B ~IN %T ］に対しても，次が満たされてはナラナイ ⇒ ［ %A の`型~list$oL[ %j ] ~EQ `bigint$T ］~AND［ %B の`型~list$oL[ %j ] は`数量-型$である ］ ◎ An effective overload set must not contain more than one item with the same type list size, where one item has a bigint argument at the distinguishing argument index and another has a numeric type argument at the distinguishing argument index.

  前の例に示された`有効-多重定義~集合$を考える。 `型~list$oL ~size %~size ~IN { 2, 3, 4 } に対するそれは、 いずれも複数の~itemを含む。 これらいずれの %~size に対しても、［ `Node^T, `Event^T ］は`判別-可能$になるので，`判別~引数~index$は 0 になる。 ◎ Consider the effective overload set shown in the previous example. There are multiple items in the set with type lists 2, 3 and 4. For each of these type list size, the distinguishing argument index is 0, since Node and Event are distinguishable.

  しかしながら，次の多重定義の利用は妥当でない： ◎ The following use of overloading however is invalid:

  [Exposed=Window]
  interface B {
    undefined f(DOMString %x);
    undefined f(USVString %x);
  };
  

  `DOMString$T と `USVString$T は判別-可能でないので。 ◎ since DOMString and USVString are not distinguishable.

• 加えて，どの %j ~IN { 0 〜 ( %~size に対する`判別~引数~index$ ~MINUS 1 ) } に対しても、 次が満たされなければナラナイ ⇒ どの［ %A, %B ~IN %T ］に対しても，次が満たされる ⇒ ［ %A の`型~list$oL[ %i ] ~EQ† %B の`型~list$oL[ %i ] ］~AND［ %A の`省略可否~list$oL[ %i ] ~EQ %B の`省略可否~list$oL[ %i ] ］ ◎ In addition, for each index j, where j is less than the distinguishing argument index for a given type list size, the types at index j in all of the items’ type lists must be the same, and the optionality values at index j in all of the items’ optionality lists must be the same.

  【† `注釈された型$とその`内縁~型$anOが，この比較において区別されるのかどうか、 はっきりしない 】

  次は妥当でない： ◎ The following is invalid:

  [Exposed=Window]
  interface B {
    /* f1 */ undefined f(DOMString %w);
    /* f2 */ undefined f(long %w, double %x, Node %y, Node %z);
    /* f3 */ undefined f(double %w, double %x, DOMString %y, Node %z);
  };
  

  引数~個数 4 に対する`有効-多重定義~集合$は： ◎ For argument count 4, the effective overload set is:

  «
    (f1, « DOMString »,                       « `必須^C »),
    (f2, « long, double, Node, Node »,        « `必須^C, `必須^C, `必須^C, `必須^C »),
    (f3, « double, double, DOMString, Node », « `必須^C, `必須^C, `必須^C, `必須^C »)
  »
  

  であり、 `型~list$oL ~size 4 の~itemを調べると， `Node^T と `DOMString$T は`判別-可能$なので、 `判別~引数~index$は 2 になる。 しかしながら，これらの 2 つの多重定義の~index 0 に位置する引数~型は異なるので、 この多重定義は妥当でない。 ◎ Looking at items with type list size 4, the distinguishing argument index is 2, since Node and DOMString are distinguishable. However, since the arguments in these two overloads at index 0 are different, the overloading is invalid.

[Exposed=Window]
interface A {
             /*---f4----*/ /*-f2-*/     /*---f1----*/    /*-f3-*/
  undefined f(
    optional ( Event     or Node     or   DOMString ) %a, /*----*/
    optional   DOMString             %b, /*---------------------*/
    optional ( DOMString or double ) %c, /*---------------------*/
               double...             %d  /*---------------------*/
  );
};

interface CanvasDrawPathExcerpt {
  undefined stroke();
  undefined stroke(Path2D %path);
};

interface CanvasDrawPathExcerptOptional {
  undefined stroke(optional Path2D %path);
};

2.5.9. 可反復~宣言

~ifcは `可反復@ （ `iterable^en ）になるように宣言できる。 そのためには、 `~ifc$の本体~内で `可反復~宣言@ （ `iterable declaration^en ） （`Iterable$g に合致-） を利用すること。 ◎ An interface can be declared to be iterable by using an iterable declaration (matching Iterable) in the body of the interface.

interface `interface_identifier^i {
  iterable<`value_type^i>;
  iterable<`key_type^i, `value_type^i>;
};

可反復として宣言された~ifcを実装している~objは、 値の連列を得するために反復できるようになる。 ◎ Objects implementing an interface that is declared to be iterable support being iterated over to obtain a sequence of values.

注記： ~JS言語束縛においては、 可反復な~ifcは，その`~ifc原型~obj$上に［ `entries^jp, `forEach^jp, `keys^jp, `values^jp, `Symbol.iterator$jI ］~propを有することになる。 ◎ Note: In the JavaScript language binding, an interface that is iterable will have entries, forEach, keys, values, and %Symbol.iterator% properties on its interface prototype object.

~parameterに与えられた型の個数が： ◎ ↓

• 1 個ならば，~ifcは `値~反復子@ （ `value iterator^en ）を有することになる — それは、 所与の型の値たちを供する。 ◎ If a single type parameter is given, then the interface has a value iterator and provides values of the specified type.＼
• 2 個ならば，~ifcは `~pair反復子@ （ `pair iterator^en ）を有することになる — それは、［ 所与の ( ~key型, 値~型 ) の値たちが成す`値~pair$ ］たちを供する。 ◎ If two type parameters are given, then the interface has a pair iterator and provides value pairs with the given types.

各 `値~pair@ （ `value pair^en ）は、 2 つの`~item$sct ( `~key$vP, `値$vP ) からなる`構造体$である： ◎ A value pair, given a key type and a value type, is a struct with two items:

1. `~key@vP は、 ~key型の~IDL値を値にとる，［ `名前$sct ~EQ `key^l ］なる`~item$sctである ◎ an item whose name is “key”, which is referred to as the value pair’s key, and whose value is an IDL value of the key type;
2. `値@vP は、 値~型の~IDL値を値にとる，［ `名前$sct ~EQ `value^l ］なる`~item$sctである ◎ an item whose name is “value”, which is referred to as the value pair’s value, and whose value is an IDL value of the value type.

`値~反復子$は、 `有index~propを~support$する~ifc上を除き，宣言してはナラナイ。 `値~反復子$の値~型は、 `有index~prop取得子$が返す型と同じでなければナラナイ。 `値~反復子$は、 暗黙的に，当の~objの有index~prop上を反復するように定義される。 ◎ A value iterator must only be declared on an interface that supports indexed properties. The value-type of the value iterator must be the same as the type returned by the indexed property getter. A value iterator is implicitly defined to iterate over the object’s indexed properties.

`~pair反復子$は、 `有index~propを~support$する~ifc上に宣言してはナラナイ。 ◎ A pair iterator must not be declared on an interface that supports indexed properties.

`~pair反復子$を伴う`~ifc$は、 付随する注釈文にて，`~ifc$の各~instanceごとに［ `反復される値~pair群@ （ `value pairs to iterate over^en ） と称される，`値~pair$たちが成す`~list$ ］を定義しなければナラナイ。 ◎ Prose accompanying an interface with a pair iterator must define a list of value pairs for each instance of the interface, which is the list of value pairs to iterate over.

注記： `配列~反復子~obj$は，このように働く。 `有index~propを~support$する ~ifcに対しては、［ `entries^jp ／ `keys^jp ／ `values^jp ／ `Symbol.iterator$jI ］から返される反復子~objは，実際の`配列~反復子~obj$である。 ◎ Note: This is how array iterator objects work. For interfaces that support indexed properties, the iterator objects returned by entries, keys, values, and %Symbol.iterator% are actual array iterator objects.

`可反復~宣言$を伴う`~ifc$の`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$／`正則~演算$ ］が在ってはナラナイ ⇒＃ `entries^l, `forEach^l, `keys^l, `values^l ◎ Interfaces with an iterable declaration must not have any attributes, constants, or regular operations named “entries”, “forEach”, “keys”, or “values”, or have any inherited interfaces that have attributes, constants, or regular operations with these names.

[Exposed=Window]
interface SessionManager {
  Session getSessionForUser(DOMString %username);

  iterable<DOMString, Session>;
};

[Exposed=Window]
interface Session {
  readonly attribute DOMString username;
  /* ... */
};

/* 
`SessionManager^T の~instanceを取得する。
2 人の利用者 `anna^l, `brian^l 用の session があるとする：
◎
Get an instance of SessionManager. Assume that it has sessions for two users, "anna" and "brian".
 */
var %sm = getSessionManager();

typeof SessionManager.prototype.values;  /*  */
var %it = %sm.values();    /* 
`values()^c は反復子~objを返す。
◎
values() returns an iterator object
 */
String(%it);              /* 
`[object SessionManager Iterator]^l に評価される。
◎
Evaluates to "[object SessionManager Iterator]"
 */
typeof %it.next;          /*  */

/* 
次の~loopは、
順に `anna^l, `brian^l を log することになる：
◎
This loop will log "anna" and then "brian".
 */
for (;;) {
  let %result = %it.next();
  if (%result.done) {
    break;
  }
  let %session = %result.value;
  console.log(%session.username);
}

/* 
次の~loopも、
順に `anna^l, `brian^l を log することになる：
◎
This loop will also log "anna" and then "brian".
 */
for (let %username of %sm.keys()) {
  console.log(%username);
}

/* 
同じことを成遂げる別の仕方：
◎
Yet another way of accomplishing the same.
 */
for (let [%username, %session] of %sm) {
  console.log(%username);
}

`可反復~宣言$を伴う~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げるものを宣言してはナラナイ ⇒＃ 別の`可反復~宣言$, `非同期に可反復な宣言$, `~maplike宣言$, `~setlike宣言$ ◎ An interface must not have more than one iterable declaration. The inherited interfaces of an interface with an iterable declaration must not also have an iterable declaration. An interface with an iterable declaration and its inherited interfaces must not have a maplike declaration, setlike declaration, or asynchronously iterable declaration.

`可反復~宣言$に適用-可能な拡張d属性は ⇒＃ `CrossOriginIsolated$x, `Exposed$x, `SecureContext$x ◎ The following extended attributes are applicable to iterable declarations: [CrossOriginIsolated], [Exposed], and [SecureContext].

2.5.10. 非同期に可反復な宣言

`~ifc$は、 非同期に可反復（ `asynchronously iterable^en ）になるように宣言できる。 そのためには、 `~ifc$の本体~内で `非同期に可反復な宣言@ （ `asynchronously iterable declaration^en ） （ `AsyncIterable$g に合致-） を利用する。 ◎ An interface can be declared to be asynchronously iterable by using an asynchronously iterable declaration (matching AsyncIterable) in the body of the interface.

interface `interface_identifier^i {
  async_iterable<`value_type^i>;
  async_iterable<`value_type^i>(/* arguments... */);
  async_iterable<`key_type^i, `value_type^i>;
  async_iterable<`key_type^i, `value_type^i>(/* arguments... */);
};

非同期に可反復になるよう宣言された`~ifc$を`実装-$する~objは、 非同期に値の連列を得するように反復できるようになる。 ◎ Objects that implement an interface that is declared to be asynchronously iterable support being iterated over asynchronously to obtain a sequence of values.

~parameterに与えられた型の個数が： ◎ ↓

• 1 個ならば，~ifcは `値を非同期に可反復な宣言@ （ `value asynchronously iterable declaration^en ） を有することになる — それは、 指定された型の値たちを非同期に供する。 ◎ If a single type parameter is given, then the interface has a value asynchronously iterable declaration and asynchronously provides values of the specified type.＼
• 2 個ならば，~ifcは `~pairを非同期に可反復な宣言@ （ `pair asynchronously iterable declaration^en ） を有することになる — それは、［ 所与の ( ~key型, 値~型 ) の値たちが成す`値~pair$ ］たちを非同期に供する。 ◎ If two type parameters are given, then the interface has a pair asynchronously iterable declaration and asynchronously provides value pairs with the given types.

`非同期に可反復な宣言$の引数たち （ `ArgumentList$g に合致-） は、 どれも`随意~引数$でなければナラナイ。 ◎ If given, an asynchronously iterable declaration’s arguments (matching ArgumentList) must all be optional arguments.

`非同期に可反復な宣言$を伴う`~ifc$ %I は、 付随する注釈文にて： ◎ Prose accompanying an interface with an asynchronously iterable declaration＼

• `次回の反復~結果を取得する手続き@ （ `get the next iteration result algorithm^en ） を定義しなければナラナイ。 それは、 所与の ⇒＃ 反復-中にある %I の~instance, 非同期c反復子~自身（状態を格納するとき有用になる） ◎ must define a get the next iteration result algorithm. This algorithm receives the instance of the interface that is being iterated, as well as the async iterator itself (which can be useful for storing state).＼

  に対し， `Promise$T を返さなければナラナイ — この`~promiseを解決する$ときの充足~値は、 次の いずれかでなければナラナイ： ◎ It must return a Promise that either rejects,＼

  • 反復の終了を通達する特別な値 `反復~終了@C ◎ resolves with a special end of iteration value to signal the end of the iteration, or＼

  • 次のいずれか： ◎ resolves with one of the following:

    • `値を非同期に可反復な宣言$用には ⇒ 当の宣言~内に与えられた型の値 ◎ for value asynchronously iterable declarations: • a value of the type given in the declaration;
    • `~pairを非同期に可反復な宣言$用には ⇒ 当の宣言に与えられた ( 1 個目の型の値, 2 個目の型の値 ) からなる`~tuple$ ◎ for pair asynchronously iterable declarations: • a tuple containing a value of the first type given in the declaration, and a value of the second type given in the declaration.

• `非同期~反復子から返る手続き@ （ `asynchronous iterator return algorithm^en ） を定義してもヨイ。 それは、 非同期c反復子が尚早に終了される事例において呼出され，所与の ⇒＃ 反復-中にある %I の~instance, 非同期c反復子~自身, `any$T 型の値をとる 1 個の引数 ◎ The prose may also define an asynchronous iterator return algorithm. This algorithm receives the instance of the interface that is being iterated, the async iterator itself, and a single argument value of type any. This algorithm is invoked in the case of premature termination of the async iterator.＼

  に対し， `Promise$T を返さなければナラナイ — この~promiseは、 充足された場合，その充足~値は無視されるが、 却下された場合，その失敗は非同期c反復子~APIの利用元へ渡されることになる。 ◎ It must return a Promise; if that promise fulfills, its fulfillment value will be ignored, but if it rejects, that failure will be passed on to users of the async iterator API.

  注記： この~algoは、 ~JS言語束縛においては［ 非同期c反復子の `return()^M ~methodが呼出されるときの挙動 ］を~custom化することを許容する。 これが最も共通的に生じるのは、 `break^c や `return^c 文により［ `for await … of^c ］~loopから抜出たときである。 ◎ In the JavaScript binding, this algorithm allows customizing the behavior when the async iterator’s return() method is invoked. This most commonly occurs when a break or return statement causes an exit from a for-await-of loop.

  注記： 類似な~hookを `throw()^M 用に追加することもできたが、 今の所，その必要性はない。 そのような能力が必要になる~APIを作成しているなら，`Enhancement request for Async Iterables$fIされたし。 ◎ We could add a similar hook for throw(). So far there has been no need, but if you are creating an API that needs such capabilities, please file an issue.

• `非同期~反復子の初期化~手続き@ （ `asynchronous iterator initialization steps^en ） を定義してもヨイ。 それは、 次を受取ることになる ⇒＃ 反復-中にある %I の~instance, 新たに作成された反復子~obj, 渡された引数たちを表現する~IDL値たちが成す`~list$ ◎ The prose may also define asynchronous iterator initialization steps. These receive the instance of the interface being iterated, the newly-created iterator object, and a list of IDL values representing the arguments passed, if any.

`非同期に可反復な宣言$を伴う`~ifc$の`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$／`正則~演算$ ］が在ってはナラナイ ⇒＃ `entries^l, `keys^l, `values^l ◎ Interfaces with an asynchronously iterable declaration must not have any attributes, constants, or regular operations named “entries”, “keys”, or “values”, or have any inherited interfaces that have attributes, constants, or regular operations with these names.

[Exposed=Window]
interface SessionManager {
  Session getSessionForUser(DOMString %username);

  async_iterable<DOMString, Session>;
};

[Exposed=Window]
interface Session {
  readonly attribute DOMString username;
  // ...
};

/* 
`SessionManager^T の~instanceを取得する。
2 人の利用者 `anna^l, `brian^l 用の session があるとする：
◎
Get an instance of SessionManager. Assume that it has sessions for two users, "anna" and "brian".
 */

var %sm = getSessionManager();

typeof SessionManager.prototype.values;  /*  */
var %it = %sm.values();    /* 
`values()^c は反復子~objを返す。
◎
values() returns an iterator object
 */
typeof %it.next;          /*  */

/* 
次の~loopは、
順に `anna^l, `brian^l を log することになる：
◎
This loop will log "anna" and then "brian".
 */
for await (let %username of %sm.keys()) {
  console.log(%username);
}

/* 
同じことを成遂げる別の仕方：
◎
Yet another way of accomplishing the same.
 */
for await (let [%username, %session] of %sm) {
  console.log(%username);
}

`非同期に可反復な宣言$を伴う~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げるものを宣言してはナラナイ ⇒＃ `可反復~宣言$, 別の`非同期に可反復な宣言$, `~maplike宣言$, `~setlike宣言$ ◎ An interface must not have more than one asynchronously iterable declaration. The inherited interfaces of an interface with an asynchronously iterable declaration must not also have an asynchronously iterable declaration. An interface with an asynchronously iterable declaration and its inherited interfaces must not have a maplike declaration, setlike declaration, or iterable declaration.

`非同期に可反復な宣言$に適用-可能な拡張d属性は ⇒＃ `CrossOriginIsolated$x, `Exposed$x, `SecureContext$x ◎ The following extended attributes are applicable to asynchronously iterable declarations: [CrossOriginIsolated], [Exposed], and [SecureContext].

これらの`拡張d属性$は、 現時点では まだ【他の仕様に】織り込まれていない。 織り込まれたときには、 その効果は，期待されるものになることになる。 ◎ these extended attributes are not currently taken into account. When they are, the effect will be as you would expect.

2.5.11. ~maplike宣言

~ifcは `~maplike@ （ `maplike^en ／ “~mapの様なもの” ）になるように宣言できる。 そのためには、 `~ifc$の本体~内で `~maplike宣言@ （ `maplike declaration^en ） （ `ReadWriteMaplike$g, `readonly^sym `MaplikeRest$g いずれかに合致-） を利用する。 ◎ An interface can be declared to be maplike by using a maplike declaration (matching ReadWriteMaplike or readonly MaplikeRest) in the body of the interface.

interface `interface_identifier^i {
  readonly maplike<`key_type^i, `value_type^i>;
  maplike<`key_type^i, `value_type^i>;
};

`~maplike$になるように宣言された~ifcを実装する~objは、［ `~map~entry群@ （ `map entries^en ） と称される，初期~時は空な`有順序~map$ ］を表現する。 この~mapを成す各`~entry$mapの［ ~key, 値 ］に利用される型は，~maplike宣言の山括弧の中で順に与えられる。 各~keyは，~map内で一意になることが要求される。 ◎ Objects implementing an interface that is declared to be maplike represent an ordered map of key–value pairs, initially empty, known as that object’s map entries. The types used for the keys and values are given in the angle brackets of the maplike declaration. Keys are required to be unique.

仕様~策定者は、 `~map~entry群$の内容を改変できる — それは、 ~JS~codeにより観測されるに伴い， 当の~objの内容~内に自動的に反映されることになる。 ◎ Specification authors can modify the contents of the map entries, which will automatically be reflected in the contents of the object as observed by JavaScript code.

~maplike~ifcは、 `~map~entry群$を~queryするための，言語束縛に適切な~APIを~supportする。 非読専な~maplike — `readonly^sym ~keywordを伴わずに宣言されたそれ — は、 `~map~entry群$を改変するための~APIも~supportする。 ◎ Maplike interfaces support an API for querying the map entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the map entries.

注記： ~JS言語束縛においては、 `~map~entry群$とヤリトリするための~APIは， ~JSにて可用な `Map$jt ~objに類似する。 `readonly^sym ~keywordが利用された場合、 それは［ `entries^jp, `forEach^jp, `get^jp, `has^jp, `keys^jp, `values^jp, `Symbol.iterator$jI ］~method, および `size^jp 取得子を含む。 非読専な~maplikeに対しては、 更に［ `clear^jp, `delete^jp, `set^jp ］~methodも含む。 ◎ Note: In the JavaScript language binding, the API for interacting with the map entries is similar to that available on JavaScript Map objects. If the readonly keyword is used, this includes entries, forEach, get, has, keys, values, %Symbol.iterator% methods, and a size getter. For read–write maplikes, it also includes clear, delete, and set methods.

~maplike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$／`正則~演算$ ］が在ってはナラナイ ⇒＃ `entries^l, `forEach^l, `get^l, `has^l, `keys^l, `size^l, `values^l ◎ Maplike interfaces must not have any attributes, constants, or regular operations named “entries”, “forEach”, “get”, “has”, “keys”, “size”, or “values”, or have any inherited interfaces that have attributes, constants, or regular operations with these names.

非読専な~maplike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$ ］が在ってはナラナイ ⇒＃ `clear^l, `delete^l, `set^l ◎ Read–write maplike interfaces must not have any attributes or constants named “clear”, “delete”, or “set”, or have any inherited interfaces that have attributes or constants with these names.

注記： 非読専な~maplike~ifcは、［ `clear^l ／ `delete^l ／ `set^l ］と命名される`正則~演算$を`伴い得る^em — それぞれは、 その~methodの既定の実装 （ `~maplike宣言＠~WEBIDLjs#js-maplike§にて定義される） を上書きすることになる。 そのような正則~演算を定義する場合、 それは，［ 各自の~methodの既定の実装~節に定義される，入力と出力に対する期待 ］に合致しなければならない。 ◎ Note: Read-write maplike interfaces can have regular operations named “clear”, “delete”, or “set”, which will override the default implementation of those methods (defined in § 3.7.11 Maplike declarations). If such regular operations are defined, they must match the input and output expectations of each method, defined in their default implementation sections.

~maplike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げるものを宣言してはナラナイ ⇒＃ `可反復~宣言$, `非同期に可反復な宣言$, 別の`~maplike宣言$, `~setlike宣言$, `有index~prop取得子$ ◎ An interface must not have more than one maplike declaration. The inherited interfaces of a maplike interface must not also have a maplike declaration. A maplike interface and its inherited interfaces must not have an iterable declaration, an asynchronously iterable declaration, a setlike declaration, or an indexed property getter.

`~maplike宣言$に適用-可能な`拡張d属性$は、 この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to maplike declarations.

例を追加する。 ◎ Add example.

2.5.12. ~setlike宣言

~ifcは `~setlike@ （ `setlike^en ／ “集合の様なもの” ）になるように宣言できる。 そのためには、 `~ifc$の本体~内で `~setlike宣言@ （ `setlike declaration^en ） （ `ReadWriteSetlike$g, `readonly^sym `SetlikeRest$g いずれかに合致-） を利用する。 ◎ An interface can be declared to be setlike by using a setlike declaration (matching ReadWriteSetlike or readonly SetlikeRest) in the body of the interface.

interface `interface_identifier^i {
  readonly setlike<`type^i>;
  setlike<`type^i>;
};

~setlikeになるように宣言された~ifcを実装する~objは、［ `~set~entry群@ （ `set entries^en ）と称される，初期~時は空な`有順序~集合$ ］を表現する。 この集合を成す各~値に利用される型は、 ~setlike宣言の山括弧の中で与えられる。 それらの値は一意になることが要求される。 ◎ Objects implementing an interface that is declared to be setlike represent an ordered set of values, initially empty, known as that object’s set entries. The type of the values is given in the angle brackets of the setlike declaration. Values are required to be unique.

仕様~策定者は、 `~set~entry群$の内容を改変できる — それは、 ~JS~codeにより観測されるに伴い， 当の~objの内容~内に自動的に反映されることになる。 ◎ Specification authors can modify the contents of the set entries, which will automatically be reflected in the contents of the object as observed by JavaScript code.

~setlike~ifcは、 `~set~entry群$を~queryするための，言語束縛に適切な~APIを~supportする。 非読専な~setlike — `readonly^sym ~keywordを伴わずに宣言されたそれ — は、 `~set~entry群$を改変するための API も~supportする。 ◎ Setlike interfaces support an API for querying the set entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the set entries.

注記： ~JS言語束縛においては、 `~set~entry群$とヤリトリするための~APIは， ~JSにて可用な `Set$jt ~objに類似する。 `readonly^sym ~keywordが利用された場合、 それは［ `entries^jp, `forEach^jp, `has^jp, `keys^jp, `values^jp, `Symbol.iterator$jI ］~method, および `size^jp 取得子を含む。 非読専な~setlikeに対しては、 更に［ `add^jp, `clear^jp, `delete^jp ］~methodも含む。 ◎ Note: In the JavaScript language binding, the API for interacting with the set entries is similar to that available on JavaScript Set objects. If the readonly keyword is used, this includes entries, forEach, has, keys, values, %Symbol.iterator% methods, and a size getter. For read–write setlikes, it also includes add, clear, and delete methods.

~setlike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$／`正則~演算$ ］が在ってはナラナイ ⇒＃ `entries^l, `forEach^l, `has^l, `keys^l, `size^l, `values^l ◎ Setlike interfaces must not have any attributes, constants, or regular operations named “entries”, “forEach”, “has”, “keys”, “size”, or “values”, or have any inherited interfaces that have attributes, constants, or regular operations with these names.

非読専な~setlike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げる名前の［ `属性$／`定数$ ］が在ってはナラナイ ⇒＃ `add^l, `clear^l, `delete^l ◎ Read–write setlike interfaces must not have any attributes or constants named “add”, “clear”, or “delete”, or have any inherited interfaces that have attributes or constants with these names.

注記： 非読専な~setlike~ifcは、［ `add^l ／ `clear^l ／ `delete^l ］と命名される`正則~演算$を`伴い得る^em — それぞれは、 その~methodの既定の実装 （ `~setlike宣言＠~WEBIDLjs#js-setlike§にて定義される） を上書きすることになる。 そのような正則~演算を定義する場合、 それは，［ 各自の~methodの既定の実装~節に定義される，入力と出力に対する期待 ］に合致しなければならない。 ◎ Note: Read-write setlike interfaces can have regular operations named “add”, “clear”, or “delete”, which will override the default implementation of those methods (defined in § 3.7.12 Setlike declarations). If such regular operations are defined, they must match the input and output expectations of each method, defined in their default implementation sections.

~setlike~ifcの`自身も含む継承した~ifc群$を成す どの~ifcにおいても、 次に挙げるものを宣言してはナラナイ ⇒＃ `可反復~宣言$, `非同期に可反復な宣言$, `~maplike宣言$, 別の`~setlike宣言$, `有index~prop取得子$ ◎ An interface must not have more than one setlike declaration. The inherited interfaces of a setlike interface must not also have a setlike declaration. A setlike interface and its inherited interfaces must not have an iterable declaration, an asynchronously iterable declaration, a maplike declaration, or an indexed property getter.

`~setlike宣言$に適用-可能な`拡張d属性$は、 この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to setlike declarations.

例を追加する。 ◎ Add example.

2.8.1. 基底 `DOMException$T ~errorの名前

下に与える `~DOMException用の名前~表t@ にて，基底 `DOMException$T ~ifcの~instance用に許容される`名前$eXを — ［ そのような各~名前が何を意味するかについての記述 ］および［ 旧来の数量-~error~code値 ］と伴に — すべて挙げる。 ◎ The DOMException names table below lists all the allowed names for instances of the base DOMException interface, along with a description of what such names mean, and legacy numeric error code values.

注記： `DOMException$T を`継承-$する~ifcは、 `~DOMException派生~ifc＠#idl-DOMException-derived-interfaces§ に述べられる方式で，各自の自前の名前 — この表tに挙げられていない名前 — を有することになる。 ◎ Interfaces inheriting from DOMException, in the manner described in § 2.8.2 DOMException derived interfaces, will have their own names, not listed in this table.

各~仕様は、 `DOMException$T 型の［ `例外を作成する$／`例外を投出する$ ］ときは，［ これらの名前のうち いずれか ］を利用しなければナラナイ。 仕様~策定者は、［ これらの名前には，自身の事例に良く収まるものが無い ］と予見する場合には， 新たな名前を共有される名前空間に追加することについて — 当の~communityがそのような労に協調できるよう — 論交するための`DOMException name proposal$fIしなければナラナイ。 利用事例に特有な新たな名前を追加することが重要になるのは、［ ~web開発者たちが、 単独の~APIから発生した複数の~error条件を差別化することになる ］ものと予見される場合に限られることに注意。 ◎ When creating or throwing a DOMException, specifications must use one of these names. If a specification author believes none of these names are a good fit for their case, they must file an issue to discuss adding a new name to the shared namespace, so that the community can coordinate such efforts. Note that adding new use-case-specific names is only important if you believe web developers will discriminate multiple error conditions arising from a single API.

“非推奨d” と~markされた `DOMException$T 名は、 旧来の目的~用に保たれたものであり，その利用eは忌避される。 ◎ The DOMException names marked as deprecated are kept for legacy purposes, but their usage is discouraged.

2.8.2. ~DOMException派生~ifc

ある例外が［ `DOMException$T の`名前$eXで供せるもの ］を超える［ ~program的に自己検分-可能な，追加的な情報 ］を運ぶ必要があるときは、 仕様~策定者は， `DOMException$T を`継承-$する`~ifc$を作成できる。 そのような`~ifc$ %~ifc は、 開発者から予測-可能な~~形をとるようにするため， 次に挙げる規則に従う必要がある： ◎ When an exception needs to carry additional programmatically-introspectable information, beyond what can be provided with a DOMException’s name, specification authors can create an interface which inherits from DOMException. Such interfaces need to follow certain rules, in order to have a predictable shape for developers. Specifically:

• %~ifc の`識別子$は、 次に従わなければナラナイ ⇒＃ `Error^c で終端する。 `~DOMException用の名前~表t$に挙げられた名前ではない。 ◎ The identifier of the interface must end with Error, and must not be any of the names in the DOMException names table.

• %~ifc は、 `構築子~演算$ — 以下 %構築子 — を有していなければナラナイ。 ◎ The interface must have a constructor operation＼
• %構築子 は、 次を遂行しなければナラナイ ⇒ `this$V の`名前$eX ~SET %~ifc の`識別子$ ◎ which sets the instance’s name to the interface’s identifier.
• %構築子 は 1 個目の~parameterとして，次に従うものをとらなければナラナイ ⇒＃ %message と命名される。 `DOMString$T 型である。 `随意~引数$であり，既定では空~文字列になる。 ◎ Their constructor operation must take as its first parameter an optional DOMString named message defaulting to the empty string,＼
• %構築子 は、 次を遂行しなければナラナイ ⇒ `this$V の`~message$eX ~SET %message ◎ and must set the instance’s message to message.
• %構築子 は、 2 個目の~parameterとして，［ 公開される必要がある追加的な情報 ］を包含している`辞書$をとるベキである — そのような辞書を成す各~mbに対し、 %~ifc は，次に従う`属性$を有するベキである ⇒＃ 同じ名前を伴う。 `読専$である。 %構築子 により受容された値を返す。 ◎ Their constructor operation should take as its second parameter a dictionary containing the additional information that needs to be exposed. ◎ They should have read only attributes, whose names are the same as the members of the constructor dictionary, which return the values accepted by the constructor operation.
• %~ifc の~instanceは、 `直列化-可能$になるベキである — その［ `直列化~手続き$／`逆直列化~手続き$ ］が当の追加的な情報を保全するよう。 ◎ They should be serializable objects, whose serialization steps and deserialization steps preserve the additional information.

注記： これらの要件は、 次を意味する ⇒ そのような~ifcが継承した `code$M ~propは、 常に 0 を返す。 【 `QuotaExceededError$T を除いて。】 ◎ These requirements mean that the inherited code property of these interfaces will always return 0.

`DOMException$T 派生~ifc用に［ `例外を作成する$／`例外を投出する$ ］ときは、 次を給する ⇒＃ その`~ifc$の`識別子$, それを構築するために必要な追加的な情報 ◎ To create or throw a DOMException derived interface, supply its interface identifier as well as the additional information needed to construct it.

2.8.3. 定義済みな `DOMException^T 派生~ifc

この標準は、 現時点では，定義済みな `DOMException$T 派生~ifcを 1 つだけ定義する： ◎ This standard so far defines one predefined DOMException derived interface:

[Exposed=*, `Serializable$]
interface `QuotaExceededError@T : `DOMException$T {
  `constructor＠#dom-quotaexceedederror-quotaexceedederror$(optional `DOMString$T %message = "", optional `QuotaExceededErrorOptions$T %options = {});

  readonly attribute `double$T? `quota$M;
  readonly attribute `double$T? `requested$M;
};

dictionary `QuotaExceededErrorOptions@T {
  `double$T `quota@mb;
  `double$T `requested@mb;
};

`QuotaExceededError$T 例外は、 ~quotaを超過したとき投出され得る。 それは、 ~web開発者からの要請について — ~quota値に比較してもっと情報を与えるため — 2 個の~propを任意選択で呈示する。 ◎ The QuotaExceededError exception can be thrown when a quota is exceeded. It has two properties that are optionally present, to give more information to the web developer about their request compared to the quota value.

注記： この標準を成す以前の~versionでは、 `QuotaExceededError^E を `基底~DOMException~error名＠#idl-DOMException-error-names$として定義した。 それは、 そのような情報を含めることを~supportするため， 全部的な~ifcへ昇格された。 ◎ Previous versions of this standard defined “QuotaExceededError” as one of the base DOMException error names. It has been upgraded to a full interface to support including such information.

注記： `QuotaExceededError$T ~ifcは、 `DOMException$T ~ifcの `code$M 取得子を継承する — それは、 常に 22 を返す。 しかしながら、 この値に依拠することは， （ `QuotaExceededError$T, `DOMException$T どちらにおいても） 忌避される — `name$M 取得子を利用する方が良い。 ◎ The QuotaExceededError interface inherits the DOMException interface’s code getter, which will always return 22. However, relying on this value is discouraged (for both QuotaExceededError and DOMException); it is better to use the name getter.

`QuotaExceededError$T ~objは、 `直列化-可能$である： ◎ QuotaExceededError objects are serializable objects.

• その`直列化~手続き$は、 所与の ( %値, %直列形 ) に対し： ◎ Their serialization steps, given value and serialized, are:

  1. `DOMException$T 用の`直列化~手続き$( %値, %直列形 ) ◎ Run the DOMException serialization steps given value and serialized.
  2. %直列形 .`Quota^sl ~SET %値 の`~quota$qEE ◎ Set serialized.[[Quota]] to value’s quota.
  3. %直列形 .`Requested^sl ~SET %値 の`要請された量$qEE ◎ Set serialized.[[Requested]] to value’s requested.

• その`逆直列化~手続き$は、 所与の ( %直列形, %値 ) に対し： ◎ Their deserialization steps, given serialized and value, are:

  1. `DOMException$T 用の`逆直列化~手続き$( %直列形, %値 ) ◎ Run the DOMException deserialization steps given serialized and value.
  2. %値 の`~quota$qEE ~SET %直列形 .`Quota^sl ◎ Set value’s quota to serialized.[[Quota]].
  3. %値 の`要請された量$qEE ~SET %直列形 .`Requested^sl ◎ Set value’s requested to serialized.[[Requested]].

`QuotaExceededError$T ［ `例外を作成する$／`例外を投出する$ ］仕様は、［ `要請された量$qEE, `~quota$qEE ］どちらも供する場合には，［ `要請された量$qEE ~LT `~quota$qEE ］を満たさなければナラナイ。 ◎ Specifications that create or throw a QuotaExceededError must not provide a requested and quota that are both non-null and where requested is less than quota.

2.13.1. `any^T

`any$T 型は、 `共用体~型$以外の，アリなすべての型の和集合である。 ◎ The any type is the union of all other possible non-union types.

`any$T 型は、 その各 値ごとに特有な非 `any$T 型が結付けられる~~点で，~~特別な共用体~型のようなものである。 例えば， `any$T 型のある値は `unsigned long$T 150 をとり得る一方、 別の値は `long$T 150 をとり得る。 これらは別個な型の値になる。 ◎ The any type is like a discriminated union type, in that each of its values has a specific non-any type associated with it. For example, one value of the any type is the unsigned long 150, while another is the long 150. These are distinct values.

`any$T 型のある値を成す特定0の型は、 その値の `特有~型@ （ `specific type^en ）と呼ばれる。 （`共用体~型$の値も`特有~型$を有する。） ◎ The particular type of an any value is known as its specific type. (Values of union types also have specific types.)

【 `any^T 型は、 `any＠~WEBIDLjs#js-any§T に見られるとおり `null^V 値もとり得るが （~JS `null^jv 値を受容し， `object?^T 型の `null^V に変換される）， “`~nullable$型である” ものとは定義されていない。 】

2.13.2. `undefined^T

`undefined$T 型は、 一意な値をとる。 【値も `undefined^V と記される。】 ◎ The undefined type has a unique value.

~IDLにおける `undefined$T 定数~値は、 `undefined^sym ~tokenで表現される。 ◎ undefined constant values in IDL are represented with the undefined token.

注記： この値は、 以前は `void^T と綴られ，許容される利用-法は もっと制限されていた。 ◎ Note: This value was previously spelled void, and more limited in how it was allowed to be used.

2.13.3. `boolean^T

`boolean$T 型は、 `真偽値$に対応する。 ◎ The boolean type corresponds to booleans.

~IDLにおいては、 `boolean$T 定数~値は［ `true^sym ／ `false^sym ］~tokenで表現される。 ◎ boolean constant values in IDL are represented with the true and false tokens.

2.13.4〜11. 整数~型

【 この訳では、 原文の § 2.12.4 〜 § 2.12.11 を成す内容 — 各種~IDL整数~型の定義を集約して，一括して与える。 】

各種 `整数~型$は、 次の表tの 2 列目に挙げるものに対応する： ◎ The (byte|short|long|long long／octet|unsigned short|unsigned long|unsigned long long) type corresponds to XXX-bit (signed|unsigned) integers. ◎ xxx constant values in IDL are represented with integer tokens.

~IDLにおいては、 どの`整数~型$も，その定数~値は `integer$g ~tokenで表現される。

2.13.12〜15. 浮動小数点数~型

【 この訳では、 原文の § 2.12.12 〜 § 2.12.15 を成す内容 — 各種~IDL浮動小数点数~型の定義を集約して，一括して与える。 】

各種 “浮動小数点数 型” — `整数~型$でない`数量-型$ — に対応する値の範囲は、 次の表tで与えられる：

~IDLにおいては、 どの浮動小数点数 型も， その定数~値は `decimal$g ~tokenで表現される。 ◎ (unrestricted )?(float|double) constant values in IDL are represented with decimal tokens.

32 ~bit浮動小数点~型を特に利用する理由が無い限り，仕様は、 `float$T ではなく`double$T を利用するべきである。 `double$T が表現できる値~集合は，より近く~JS `Number^jt に合致するので。 ◎ Unless there are specific reasons to use a 32-bit floating point type, specifications should use double rather than float, since the set of values that a double can represent more closely matches a JavaScript Number.

2.13.16. `bigint^T

`bigint$T 型は、 範囲が制約されない任意な整数をとり得る。 ◎ The bigint type is an arbitrary integer type, unrestricted in range.

~IDLにおける `bigint$T 定数~値は、 `integer$g ~tokenで表現される。 ◎ bigint constant values in IDL are represented with integer tokens.

2.13.17. `DOMString^T

`DOMString$T 型は、 `文字列$たちに対応する。 ◎ The DOMString type corresponds to strings.

注記： `null^V は `DOMString$T 型の値ではないことに注意。 ~IDLにおいて `null^V を許容するためには、［ `DOMString?^sym と記される`~nullable$ `DOMString$T ］を利用する必要がある。 ◎ Note: null is not a value of type DOMString. To allow null, a nullable DOMString, written as DOMString? in IDL, needs to be used.

注記： `DOMString$T 値は、 対を成さない`~surrogate符号位置$も含み得る。 それが望ましくない場合は、 `USVString$T を利用すること。 ◎ Note: A DOMString value might include unmatched surrogate code points. Use USVString if this is not desirable.

~IDLにおいては、 `DOMString$T 値を定数として表現する仕方は無い。 `DOMString$T 型の［ `辞書~mb$ ／ 演算の`随意~引数$ ］に対し，その［ `既定~値$diC ／ `既定~値$ ］を［ `string$g ~literalによる`値$stR ］に設定することはできるが。 ◎ There is no way to represent a constant DOMString value in IDL, although DOMString dictionary member default values and operation optional argument default values can be set to the value of a string literal.

2.13.18. `ByteString^T

`ByteString$T 型は、 `~byte列$たちに対応する。 ◎ The ByteString type corresponds to byte sequences.

~IDLにおいては、 `ByteString$T 値を定数として表現する仕方は無い。 `ByteString$T 型の［ `辞書~mb$ ／ 演算の`随意~引数$ ］に対し，その［ `既定~値$diC ／ `既定~値$ ］を［ `string$g ~literalによる`値$stR ］に設定することはできるが。 ◎ There is no way to represent a constant ByteString value in IDL, although ByteString dictionary member default values and operation optional argument default values can be set to the value of a string literal.

仕様は、［ HTTP など，~byteと文字列を交換-可能に利用する~protocol ］を~ifc化するときに限り， `ByteString$T を利用するべきである。 一般に，文字列は、 その値が［ 常に ASCII または 何らかの 8 ~bit文字~符号化法 ］になることが期待されているとしても， `DOMString$T 値で表現するべきである。 8 ~bit~dataを保持するためには、 `ByteString$T ではなく，［ `octet$T か `byte$T ］を要素とする［ `連列~型$ ／ `凍結d配列~型$ ／ `Uint8Array$T ／ `Int8Array$T ］を利用するべきである。 ◎ Specifications should only use ByteString for interfacing with protocols that use bytes and strings interchangeably, such as HTTP. In general, strings should be represented with DOMString values, even if it is expected that values of the string will always be in ASCII or some 8-bit character encoding. Sequences or frozen arrays with octet or byte elements, Uint8Array, or Int8Array should be used for holding 8-bit data rather than ByteString.

2.13.19. `USVString^T

`USVString$T 型は、 `~scalar値~文字列$たちに対応する。 これらは，文脈に依存して，［ `符号単位$たちが成す連列 ］としても［ `~scalar値$たちが成す連列 ］としても扱われ得る。 ◎ The USVString type corresponds to scalar value strings. Depending on the context, these can be treated as sequences of code units or scalar values.

~IDLにおいては、 `USVString$T 値を定数として表現する仕方は無い。 `USVString$T 型の［ `辞書~mb$ ／ 演算の`随意~引数$ ］に対し，その［ `既定~値$diC ／ `既定~値$ ］を［ `string$g ~literalによる`値$stR ］に設定することはできるが。 ◎ There is no way to represent a constant USVString value in IDL, although USVString dictionary member default values and operation optional argument default values can be set to the value of a string literal.

仕様は、［ ~text処理を遂行する際に，`~scalar値$たちが成す文字列に対する演算が必要になる ］ときに限り， `USVString$T を~APIに利用するべきである。 文字列を利用する ほとんどの~APIは、 文字列~内の`符号単位$に いかなる解釈も行わない `DOMString$T を利用するべきである。 疑わしい場合は `DOMString$T を利用すること。 ◎ Specifications should only use USVString for APIs that perform text processing and need a string of scalar values to operate on. Most APIs that use strings should instead be using DOMString, which does not make any interpretations of the code units in the string. When in doubt, use DOMString.

2.13.20. `object^T

`object$T 型は、 アリなすべての［ 非 `null^V ~obj参照 ］が成す集合に対応する。 ◎ The object type corresponds to the set of all possible non-null object references.

~IDLにおいては、 `object$T 値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant object value in IDL.

アリなすべての~obj参照に加えて， `null^V 値も内包する型を表すためには、 `~nullable型$ `object?^T を利用すること。 ◎ To denote a type that includes all possible object references plus the null value, use the nullable type object?.

2.13.21. `symbol^T

`symbol$T 型は、 アリなすべての~symbol値が成す集合に対応する。 ~symbol値は、 不透明かつ `object$T でない値であるが， 同一性（ `identity^en ）は備える（すなわち、自身のみに等しい）。 ◎ The symbol type corresponds to the set of all possible symbol values. Symbol values are opaque, non-object values which nevertheless have identity (i.e., are only equal to themselves).

~IDLにおいては、 `symbol$T 値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant symbol value in IDL.

2.13.22. ~ifc型

`~ifc$を識別する`識別子$は、 その~ifcを実装する［ アリなすべての非 `null^V ~obj参照が成す集合 ］に対応する型を指すために利用される。 ◎ An identifier that identifies an interface is used to refer to a type that corresponds to the set of all possible non-null references to objects that implement that interface.

~ifc型の~IDL値は，単に~obj参照により表現される。 ◎ An IDL value of the interface type is represented just by an object reference.

~IDLにおいて，特定0の~ifc型~用の~obj参照~値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant object reference value for a particular interface type in IDL.

［ 所与の~ifcを実装する アリなすべての~obj参照に加え， `null^V 値も内包する ］ような型を表すためには、 `~nullable型$を利用すること。 ◎ To denote a type that includes all possible references to objects implementing the given interface plus the null value, use a nullable type.

2.13.23. ~callback~ifc型

`~callback~ifc$を識別する`識別子$は、［ アリなすべての非 `null^V ~obj参照が成す集合 ］に対応する型を指すために利用される。 ◎ An identifier that identifies a callback interface is used to refer to a type that corresponds to the set of all possible non-null references to objects.

この~ifc型の~IDL値は［ ~obj参照, `~callback文脈$ ］の組により表現される。 `~callback文脈@ （ `callback context^en ）とは、 言語束縛に特有な値であり，［ 言語束縛に特有な~obj参照が`~IDL値に変換-$される時点 ］における［ 実行~文脈についての情報 ］を格納するために利用される。 ◎ An IDL value of the interface type is represented by a tuple of an object reference and a callback context. The callback context is a language binding specific value, and is used to store information about the execution context at the time the language binding specific object reference is converted to an IDL value.

注記： ~JS~objに対しては、 `~callback文脈$は，［ `Object^jt 値が~IDL~callback~ifc型の値に変換される時点の，`現任な設定群~obj$ ］への参照を保持するために利用される。 `~callback~ifc型＠~WEBIDLjs#js-callback-interface§を見よ。 ◎ Note: For JavaScript objects, the callback context is used to hold a reference to the incumbent settings object at the time the Object value is converted to an IDL callback interface type value. See § 3.2.16 Callback interface types.

~IDLにおいては、 特定0の`~callback~ifc型$用の~obj参照~値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant object reference value for a particular callback interface type in IDL.

［ アリなすべての~obj参照に加え， `null^V 値も内包する ］ような型を表すためには、 `~nullable型$を利用すること。 ◎ To denote a type that includes all possible references to objects plus the null value, use a nullable type.

2.13.24. 辞書~型

`辞書$を識別する`識別子$は、［ 当の辞書~定義を固守する，すべての辞書が成す集合 ］に対応する型を指すために利用される。 ◎ An identifier that identifies a dictionary is used to refer to a type that corresponds to the set of all dictionaries that adhere to the dictionary definition.

`有順序~map$用の~literal構文も，辞書を表現するために利用できる — 文脈から暗黙的に［ 当の~mapは、 特定の辞書~型の~instanceとして扱われる ］ものと解されるならば。 しかしながら、 ~IDL片の内側では，辞書~値を定数として表現する仕方は無い。 ◎ The literal syntax for ordered maps may also be used to represent dictionaries, when it is implicitly understood from context that the map is being treated as an instance of a specific dictionary type. However, there is no way to represent a constant dictionary value inside IDL fragments.

2.13.25. 列挙~型

`列挙$を識別する`識別子$は、［ その`列挙~値$に属する文字列 （ `DOMString$T と同じく，`符号単位$たちが成す連列） ］を値にとる型を指すために利用される。 ◎ An identifier that identifies an enumeration is used to refer to a type whose values are the set of strings (sequences of code units, as with DOMString) that are the enumeration’s values.

`DOMString$T と同様に， ~IDLにおいては、 `列挙$値を定数として表現する仕方は無い。 列挙~型の［ `辞書~mb$ ／ 演算の`随意~引数$ ］に対し，その［ `既定~値$diC ／ `既定~値$ ］を［ `string$g ~literalによる`値$stR ］に設定することはできるが。 ◎ Like DOMString, there is no way to represent a constant enumeration value in IDL, although enumeration-typed dictionary member default values and operation optional argument default values can be set to the value of a string literal.

2.13.26. ~callback関数~型

`~callback関数$を識別する`識別子$は、［ 所与の~signatureを伴う関数~objへの参照 ］を値にとる型を指すために利用される。 ◎ An identifier that identifies a callback function is used to refer to a type whose values are references to objects that are functions with the given signature.

注記： `~callback関数$の定義に `LegacyTreatNonObjectAsNull$x 拡張d属性が指定された場合、 関数でない~objへの参照も値にとり得る。 ◎ Note: If the [LegacyTreatNonObjectAsNull] extended attribute is specified on the definition of the callback function, the values can be references to objects that are not functions.

~callback関数~型の~IDL値は，［ ~obj参照, `~callback文脈$ ］の組により表現される。 ◎ An IDL value of the callback function type is represented by a tuple of an object reference and a callback context.

注記： `~callback~ifc型$のときと同じく，`~callback文脈$は、［ ~JS `Object^jt 値が~IDL~callback~ifc型の値に変換される時点の，`現任な設定群~obj$への参照 ］を保持するために利用される。 `~callback関数~型＠~WEBIDLjs#js-callback-function§を見よ。 ◎ Note: As with callback interface types, the callback context is used to hold a reference to the incumbent settings object at the time a JavaScript Object value is converted to an IDL callback function type value. See § 3.2.19 Callback function types.

~IDLにおいては、 `~callback関数$値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant callback function value in IDL.

2.13.27. ~nullable型 — `T?^T

`~nullable型@ （ `nullable type^en ）は、 （その `内縁~型@ （ `inner type^en ） と呼ばれる） 既存の型から構築される~IDL型であり、 とり得る値が成す集合は，内縁~型がとり得る値に値 `null^V のみを~~追加したものになる。 ~IDLにおいては、 `~nullable型$は，既存の型の後に文字 `003F^U1 を置いて表現される。 `内縁~型$は、 次に挙げるもの以外でなければナラナイ： ◎ A nullable type is an IDL type constructed from an existing type (called the inner type), which just allows the additional value null to be a member of its set of values. Nullable types are represented in IDL by placing a U+003F (?) character after an existing type. The inner type must not be:

注記： 辞書~型は，一般には~nullableになれるが、 その場合，演算~引数や辞書~mbの型には利用できない。 ◎ Note: Although dictionary types can in general be nullable, they cannot when used as the type of an operation argument or a dictionary member.

~IDLにおいては、 ~nullable型の定数~値は，その`内縁~型$の定数~値と同じ仕方で表現されるか, または `null^sym ~tokenで表現される。 ◎ Nullable type constant values in IDL are represented in the same way that constant values of their inner type would be represented, or with the null token.

[Exposed=Window]
interface NetworkFetcher {
  undefined get(optional boolean? areWeThereYet = false);
};

[Exposed=Window]
interface Node {
  readonly attribute DOMString? namespaceURI;
  readonly attribute Node? parentNode;
  /* ... */
};

2.13.28. 連列~型 — ~sequence_T

`連列~型@ （ `sequence type^en ） — ~sequence_T — は、 ~parameter化された型であり， 型 %T の値たちが成す`~list$を値にとる。 ◎ The sequence<T> type is a parameterized type whose values are (possibly zero-length) lists of values of type T.

連列は、 常に，値により渡される。 連列が何らかの種類の~objで表現される言語束縛においても、 `~platform~obj$に連列が渡された際に，当の連列への参照が~objに保有されることはない。 類似に，~platform~objから返されるどの連列も複製であり、 それに対し為される改変は~platform~objからは可視にならないことになる。 ◎ Sequences are always passed by value. In language bindings where a sequence is represented by an object of some kind, passing a sequence to a platform object will not result in a reference to the sequence being kept by that object. Similarly, any sequence returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

`~list$用の~literal構文も，連列を表現するために利用できる — 文脈から暗黙的に［ 当の~listは、 ある連列の~instanceとして扱われる ］ものと解されるならば。 しかしながら、 ~IDL片の内側では，連列~値を定数として表現する仕方は無い。 ◎ The literal syntax for lists may also be used to represent sequences, when it is implicitly understood from context that the list is being treated as a sequences. However, there is no way to represent a constant sequence value inside IDL fragments.

連列は、［ `属性$／`定数$ ］の型として利用してはナラナイ。 ◎ Sequences must not be used as the type of an attribute or constant.

注記： この制約は、［ `連列~型$は、 その参照が渡し回されるものではなく，複製されるものである ］ことを，仕様の［ 策定者／利用者 ］から見て明瞭にするためにある。 連列~型の~writableな`属性$には、 代わりに，連列を［ 取得する, 設定する ］`演算$~pairの利用が示唆される。 ◎ Note: This restriction exists so that it is clear to specification writers and API users that sequences are copied rather than having references to them passed around. Instead of a writable attribute of a sequence type, it is suggested that a pair of operations to get and set the sequence is used.

`~list$は、 次を満たすならば，暗黙的に ~sequence_T 型の値として扱える ⇒ ~listを成すどの`~item$も %T 型である ◎ Any list can be implicitly treated as a sequence<T>, as long as it contains only items that are of type T.

2.13.29. 非同期c連列~型 — ~async_sequence_T

`非同期c連列~型@ （ `async sequence type^en ） — ~async_sequence_T — は、 ~parameter化された型であり， 次を生産できる~objへの参照を値にとる ⇒ 非同期に反復-可能な — 場合によっては無限な — 型 %T の値たちが成す連列 ◎ An async sequence type is a parameterized type whose values are references to objects that can produce an asynchronously iterable, possibly infinite, sequence of values of type T.

`連列$ （それは、 固定長な~listであり，すべての値は事前に既知である） とは違って、 非同期c連列により作成される非同期に反復-可能な連列は，~lazy（後回し）である。 それを成す値たちは、 反復の間に限り非同期に生産され得る — したがって，［ それを成す値たち／長さ ］は、 当の非同期c連列が作成された時点では，既知でないかもしれない。 ◎ Unlike sequences, which are fixed-length lists where all values are known in advance, the asynchronously iterable sequences created by async sequences are lazy. Their values may be produced asynchronously only during iteration, and thus the values or length might not be known at the time the async sequence is created.

非同期c連列は、 言語~束縛においては，参照により渡される — そこでは、 ある~objにより表現される。 このことは、［ 非同期c連列を`~platform~obj$へ渡した結果 ］は［ その~objにより保たれている非同期c連列への参照 ］になることを意味する。 類似に， ~platform~objから返される どの非同期c連列も同じ~objへの参照になり、 それに対し為される改変は，~platform~objからも可視になる — 常に値により渡される連列とは対照的に。 ◎ Async sequences are passed by reference in language bindings where they are represented by an object. This means that passing an async sequence to a platform object will result in a reference to the async sequence being kept by that object. Similarly, any async sequence returned from a platform object will be a reference to the same object and modifications made to it will be visible to the platform object. This is in contrast to sequences, which are always passed by value.

注記： 非同期c連列は、 ~IDLからは構築し得ない。 非同期c連列は、［ ある演算から返される場合／ 辞書~memberの型として利用される場合 ］には，~host環境から出生したものが言語~束縛を介して~IDL型へ転換されることになる。 ~IDL演算は、 非同期c連列を返す代わりに，`非同期に可反復な宣言$を有する`~ifc$を返すよう求めることもあろう。 ◎ Note: Async sequences cannot be constructed from IDL. If returned from an operation, or used as the type of a dictionary member, the async sequence will have originated from the host environment and have been turned into an IDL type via a language binding. Instead of returning an async sequence from an IDL operation, the operation might want to return an interface that has an asynchronously iterable declaration.

`非同期c連列~型$は、［ `属性$／`定数$ ］の型として利用してはナラナイ。 ◎ Async sequences must not be used as the type of an attribute or constant.

~IDLにおいては、 非同期c連列~値を定数として表現する仕方は無い。 ◎ There is no way to represent an async sequence value in IDL.

2.13.30. ~record型 — ~record_KV

`~record型@ （ `record type^en ） — ~record_KV — は、 ~parameter化された型であり， 次を満たす`有順序~map$を値にとる ⇒ それを成す各`~entry$mapは、 次を満たす ⇒ ［ その`~key$mapは型 %K の ある~instanceである ］~AND［ その`値$mapは型 %V の ある~instanceである ］ ◎ A record type is a parameterized type whose values are ordered maps with keys that are instances of K and values that are instances of V.＼

%K は、［ `DOMString$T ／ `USVString$T ／ `ByteString$T ］でなければナラナイ。 ◎ K must be one of DOMString, USVString, or ByteString.

`有順序~map$用の~literal構文も，~recordを表現するために利用できる — 文脈から暗黙的に［ 当の~mapは、 ~record型の~instanceとして扱われる ］ものと解されるならば。 しかしながら、 ~IDL片の内側では，~record値を定数として表現する仕方は無い。 ◎ The literal syntax for ordered maps may also be used to represent records, when it is implicitly understood from context that the map is being treated as a record. However, there is no way to represent a constant record value inside IDL fragments.

~recordは常に値により渡される。 ~recordが何らかの種類の~objで表現される言語束縛においても、 `~platform~obj$に~recordが渡された際に，当の~recordへの参照が~objに保有されることはない。 類似に，~platform~objから返されるどの~recordも複製であり、 それに対し為される改変は~platform~objからは可視にならないことになる。 ◎ Records are always passed by value. In language bindings where a record is represented by an object of some kind, passing a record to a platform object will not result in a reference to the record being kept by that object. Similarly, any record returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

~recordは、［ `属性$／`定数$ ］の型として利用してはナラナイ。 ◎ Records must not be used as the type of an attribute or constant.

`有順序~map$は、 次を満たすならば，暗黙的に ~record_KV 型の値として扱える ⇒ ~mapを成すどの`~entry$mapも，その［ `~key$mapは %K 型, `値$mapは %V 型 ］である ◎ Any ordered map can be implicitly treated as a record<K, V>, as long as it contains only entries whose keys are all of of type K and whose values are all of type V.

2.13.31. ~promise型 — ~promise_T

`~promise型@ （ `promise type^en ） — ~promise_T — は、 ~parameter化された型であり， 次として利用される~objへの参照を値にとる ⇒ “［ 非同期な演算において，先送りされ得る（非同期にもなり得る）算出 ］の最終的な結果†を保持するための場（ `place holder^en ）” `ECMA-262$r 【† %T が，充足-時における結果の値の型を与える。】 ◎ A promise type is a parameterized type whose values are references to objects that “is used as a place holder for the eventual results of a deferred (and possibly asynchronous) computation result of an asynchronous operation”.＼

~promise~objの意味論についての詳細は、 ~JS仕様 `25.4＠~TC39#sec-promise-objects§ を見よ。 ◎ See section 25.4 of the JavaScript specification for details on the semantics of promise objects.

~promise型は~nullableでないが、 %T は~nullableでもヨイ。 ◎ Promise types are non-nullable, but T may be nullable.

~IDLにおいては、 ~promise値を表現する仕方は無い。 ◎ There is no way to represent a promise value in IDL.

2.13.32. 共用体~型

`共用体~型@ （ `union type^en ）は、 とり得る値が成す集合が［ 複数の型の，それぞれがとり得る値が成す集合 ］の和集合であるような，型である。 共用体~型 （ `UnionType$g に合致-） は、 ~keyword `or^sym で分離された型たちを丸括弧で括って記される。 共用体~型を構成する各~型は、 共用体の `~mb型@ （ `member type^en ）と呼ばれる。 ◎ A union type is a type whose set of values is the union of those in two or more other types. Union types (matching UnionType) are written as a series of types separated by the or keyword with a set of surrounding parentheses. The types which comprise the union type are known as the union’s member types.

`any$T 型と同様、 共用体~型の値は，その値に合致する特定0の`~mb型$を`特有~型$として有する。 ◎ Like the any type, values of union types have a specific type, which is the particular member type that matches the value.

注記： 例えば，`共用体~型$ `(Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>)^T の`平坦~化~mb型~群$は、 次に挙げる 6 つの型からなる ⇒＃ `Node^T, `sequence<long>^T, `Event^T, `XMLHttpRequest^T, `DOMString^T, `sequence<(sequence<double> or NodeList)>^T ◎ Note: For example, the flattened member types of the union type (Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>) are the six types Node, sequence<long>, Event, XMLHttpRequest, DOMString and sequence<(sequence<double> or NodeList)>.

`~mb型$には、 `any$T 型を利用してはナラナイ。 ◎ The any type must not be used as a union member type.

`共用体~型$の`~nullable~mb型の個数$は 0 か 1 でなければナラナイ。 1 の場合、 その共用体~型は`平坦~化~mb型~群$に`辞書~型$を含んではナラナイ。 ◎ The number of nullable member types of a union type must be 0 or 1, and if it is 1 then the union type must also not have a dictionary type in its flattened member types.

~OR↓ を満たす型は `~nullable型を内包する@ （ `includes a nullable type^en ）とされる。 ◎ A type includes a nullable type if:

• `~nullable型$である ◎ the type is a nullable type, or
• ［ `注釈された型$である ］~AND［ その`内縁~型$anOは`~nullable型$である ］ ◎ the type is an annotated type and its inner type is a nullable type, or
• ［ `共用体~型$である ］~AND［ その `~nullable~mb型の個数$は 0 でない（ 1 である） ］ ◎ the type is a union type and its number of nullable member types is 1.

【 概念的には， `null^V を値にとり得る型と考えられる。 ただし、 この定義では `any$T 型は含まれないことになる。 】

`共用体~型$の`平坦~化~mb型~群$に属する どの 2 つの型も`判別-可能$でなければナラナイ。 ◎ Each pair of flattened member types in a union type, T and U, must be distinguishable.

［ `bigint$T, `数量-型$ ］が成す共用体を作成することはアリであるが、 一般に，その利用は、 `NumberFormat$jt などの［ それを計算には利用せず，値を整形するような~ifc ］用に限られるものと想定されている。 そのような共用体を受容しつつ，`数量-型$の値に対しては単に `bigint$T に変換してから処理するのは、 適切でない — それは、 精度~errorを導入する~riskを冒すことになるので。 この特能を利用するときは、 その前に， `Intent to use bigint/numeric union$fIされたし。 ◎ It is possible to create a union of bigint and a numeric type. However, this is generally only supposed to be used for interfaces such as NumberFormat, which formats the values rather than using them in calculations. It would not be appropriate to accept such a union, only to then convert values of the numeric type to a bigint for further processing, as this runs the risk of introducing precision errors. Please file an issue before using this feature.

~OR↓ を満たす型は、 `~undefinedを内包する@ （ `includes undefined^en ）とされる： ◎ A type includes undefined if:

• `undefined$T 型である ◎ the type is undefined, or
• ［ `~nullable型$である ］~AND［ その`内縁~型$は`~undefinedを内包する$ ］ ◎ the type is a nullable type and its inner type includes undefined, or
• ［ `注釈された型$である ］~AND［ その`内縁~型$anOは`~undefinedを内包する$ ］ ◎ the type is an annotated type and its inner type includes undefined, or
• ［ `共用体~型$である ］~AND［ その`~mb型$のうちいずれかは、 `~undefinedを内包する$ ］ ◎ the type is a union type and one of its member types includes undefined.

~IDLにおいては、 `共用体~型$の定数~値は，それらの`~mb型$の定数~値と同じ仕方で表現される。 ◎ Union type constant values in IDL are represented in the same way that constant values of their member types would be represented.

2.13.33. 注釈された型

既存の型に ある種の`拡張d属性$を指定することにより，追加的な型を作成できる。 そのような型は， `注釈された型@ （ `annotated type^en ）と呼ばれ、 注釈された~~元の型は，その `内縁~型@anO （ `inner type^en ）と呼ばれる。 ◎ Additional types can be created from existing ones by specifying certain extended attributes on the existing types. Such types are called annotated types, and the types they annotate are called inner types.

`[Clamp] long^c は、 新たな`注釈された型$を定義する — その挙動は `内縁~型$anO `long$T に基づくが， `Clamp$x 拡張d属性に指定されるとおり改変される。 ◎ [Clamp] long defines a new annotated type, whose behavior is based on that of the inner type long, but modified as specified by the [Clamp] extended attribute.

次に挙げるものが `型に適用-可能@ （ `applicable to type^en ）な拡張d属性とされる ⇒ `AllowResizable$x, `AllowShared$x, `Clamp$x, `EnforceRange$x, `LegacyNullToEmptyString$x ◎ The following extended attributes are applicable to types: [AllowResizable], [AllowShared], [Clamp], [EnforceRange], and [LegacyNullToEmptyString].

どの型に対しても，それに`結付けられた拡張d属性$は、 `型に適用-可能$でなければナラナイ。 ◎ For any type, the extended attributes associated with it must only contain extended attributes that are applicable to types.

2.13.34. ~buffer~source型

アリなすべての［［［ ~dataの~buffer, または［ ~dataの~bufferの~view ］］を表現する~obj ］への非 `null^V 参照 ］が成す集合に対応する，いくつかの型がある。 下の表tに、 それらの型, および それらが表現する［ ~bufferまたは その~view ］の種類を挙げる。 ◎ There are a number of types that correspond to sets of all possible non-null references to objects that represent a buffer of data or a view on to a buffer of data. The table below lists these types and the kind of buffer or view they represent.

注記： これらの型はすべて、 ~JSにて定義される~classに対応する。 ◎ Note: These types all correspond to classes defined in JavaScript.

これらのどの型も， ~IDLにおいては、 その型の値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant value of any of these types in IDL.

仕様の中の注釈文~levelにおいては、 ~IDL`~buffer~source型$は，単純に~objへの参照である。 仕様の注釈文は、 ~buffer内の~byte列を検分したり操作するときは， `~buffer~source型＠~WEBIDLjs#js-buffer-source-types§にて与える~algoを利用する必要がある。 ◎ At the specification prose level, IDL buffer source types are simply references to objects. To inspect or manipulate the bytes inside the buffer, specification prose needs to use the algorithms in § 3.2.26 Buffer source types.

2.13.35. 凍結d配列~型 — ~FrozenArray_T

`凍結d配列~型@ （ `frozen array type^en ） — ~FrozenArray_T — は、 ~parameter化された型であり，［ 型 %T の値たちが成す，長さが固定的かつ改変-不能な配列 ］を保持する~objへの参照を値にとる。 ◎ A frozen array type is a parameterized type whose values are references to objects that hold a fixed length array of unmodifiable values. The values in the array are of type T.

`凍結d配列~型$は、 `~ifc$上に定義される［ `正則~属性$／`静的~属性$ ］の型として利用でき， それら以外に利用してはナラナイ。 ◎ Frozen array types must only be used as the type of regular attributes or static attributes defined on an interface.

[Exposed=Window]
interface PersonalPreferences {
    readonly attribute FrozenArray<DOMString> favoriteColors;
    attribute FrozenArray<DOMString> favoriteFoods;

    undefined randomizeFavoriteColors();
};

`連列$ （それは、 値たちが成す~listであり，値により渡される） とは違って、 凍結d配列~値は参照である。 ◎ Since FrozenArray<T> values are references, they are unlike sequence types, which are lists of values that are passed by value.

~IDLにおいては、 凍結d配列~値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant frozen array value in IDL.

2.13.36. 観測-可能な配列~型 — ~ObservableArray_T

`観測-可能な配列~型@ （ `observable array type^en ）は、 ~parameter化された型であり， 次の組合nへの参照を値にとる ⇒＃ 0 個以上の型 %T の~objからなる変異-可能な~list【 “観測-可能な配列” 】, 作者~codeがこの~listの内容を改変したときに遂行する挙動 ◎ An observable array type is a parameterized type whose values are references to a combination of a mutable list of objects of type T, as well as behavior to perform when author code modifies the contents of the list.

【 “観測-可能な” は、 “配列~型” ではなく，“配列” を形容する （他の “観測-可能な配列〜” も同様） — “観測-可能~配列” と記すこともできたが、 過度な漢字の連続は視覚的に認識しづらいので。 】

この~parameter化される型 %T は、［ `辞書~型$／`連列~型$／`~record型$／`観測-可能な配列~型$ ］であってはナラナイが，`~nullable$でもヨイ。 ◎ The parameterized type T must not be a dictionary type, sequence type, record type, or observable array type. However, T may be nullable.

観測-可能な配列~型は — `連列~型$, `凍結d配列~型$と同様に — ~JS配列~型を包装して，その用法に対し追加的な意味論を課す。 ◎ Similar to sequence types and frozen array types, observable array types wrap around JavaScript array types, imposing additional semantics on their usage.

観測-可能な配列~型は、［ `~ifc$上に定義された`正則~属性$ ］の型~以外には，利用してはナラナイ。 ◎ Observable array types must only be used as the type of regular attributes defined on an interface.

仕様~策定者は、 観測-可能な配列~型である属性~用に，次に挙げる~algoを指定できる： ◎ For an attribute whose type is an observable array type, specification authors can specify a series of algorithms:

`観測-可能な配列~属性の有index値を設定する@ （ `set an indexed value^en ） ◎ set an indexed value,＼

( %値, %~index ) を受容する — %値 は、 当の観測-可能な配列~内の~index %~index に設定されようとしている~IDL値を与える。 ◎ which accepts an IDL value that is about to be set in the observable array, and the index at which it is being set;

`観測-可能な配列~属性の有index値を削除する@ （ `delete an indexed value^en ） ◎ delete an indexed value,＼

( %値, %~index ) を受容する — %値 は、 当の観測-可能な配列~内の~index %~index から除去されようとしている~IDL値を与える。 ◎ which accepts an IDL value that is about to be removed from the observable array, and the index from which it is being removed.

~JS~codeが既存の~indexを新たな値に設定するとき、 これは，まず［ `観測-可能な配列~属性の有index値を削除する$~algoを~callして既存の値を除去して ］から［ 新たな値で`観測-可能な配列~属性の有index値を設定する$~algoを~callする ］ことに注意。 ◎ Note that when JavaScript code sets an existing index to a new value, this will first call the delete an indexed value algorithm to remove the existing value, and then the set an indexed value algorithm with the new value.

各`正則~属性$のうち，その型は`観測-可能な配列~型$であるものには、 それを `~backしている~list@ （ `backing list^en ）がある。 それは、 `~list$であり，初期~時には空とする。 仕様~策定者は、 ~backしている~listの内容を改変できる — それは、 ~JS~codeにより観測されるに伴い，自動的に観測-可能な配列の内容に反映されることになる。 類似に、 この観測-可能な配列の内容に対する，~JS~codeによる どの改変も — ［ `観測-可能な配列~属性の有index値を設定する$, `観測-可能な配列~属性の有index値を削除する$ ］~algoを通過した後に — ~backしている~listの中へ【！back into】反映されることになる。 ◎ Every regular attribute whose type is an observable array type has a backing list, which is a list, initially empty. Specification authors can modify the contents of the backing list, which will automatically be reflected in the contents of the observable array as observed by JavaScript code. Similarly, any modifications by JavaScript code to the contents of the observable array will be reflected back into the backing list, after passing through the set an indexed value and delete an indexed value algorithms.

~IDLにおいては、 観測-可能な配列~値を定数として表現する仕方は無い。 ◎ There is no way to represent a constant observable array value in IDL.

[Exposed=Window]
interface Building {
  attribute ObservableArray<Employee> employees;
};

/* 
`Building^T の~instanceを取得する。
◎
Get an instance of Building.
 */
const %building = getBuilding();

%building.employees.push(new Employee("A"));
%building.employees.push(new Employee("B"));
%building.employees.push(new Employee("C"));

%building.employees.splice(2, 1);
const employeeB = %building.employees.pop();

%building.employees = [new Employee("D"), employeeB, new Employee("C")];

%building.employees.length = 0;

/* 
次は例外を投出することになる：
◎
Will throw:
 */
%building.employees.push("Employee ではなく文字列");

const %normalArray = [];

/* 
`employees^M の型を`有index~prop取得子$を伴う~ifcとして定義した場合、
%normalArray は 1 個の~item
— `employees^M の値 —
を包含することになろう。
観測-可能な配列~型（あるいは凍結d配列~型）であれば、
%normalArray は `employees^M の内側にある すべての~itemを包含することになる。
◎
If building.employees were defined as an indexed property getter interface: normalArray would contains a single item, building.employees.
◎
For observable arrays (and frozen arrays): normalArray contains all of the items inside of building.employees.
 */
%normalArray.concat(%building.employees);

/* 
%names は~JS `Array^jt 。
◎
names is a JavaScript Array.
 */
const %names = %building.employees.map(%employee => %employee.name);

/* 
各種~brand検査にも合格する：
◎
Passes various brand checks:
 */
console.assert(%building.employees instanceof Array);
console.assert(Array.isArray(%building.employees));
console.assert(%building.employees.constructor === Array);

/* 
`JSON.stringify^c においてさえ配列として扱われる（外縁の `[]^c に注意）：
◎
Even is treated as an array by JSON.stringify! (Note the outer []s.)
 */

console.assert(JSON.stringify(%building.employees) === ``^[{}]``^);