step notes

step_notes.txt

<emu-note>
          <p>The object that may be created in step 5.a.ii is not accessible outside of the above abstract operation and the ordinary object [[Get]] internal method. An implementation might choose to avoid the actual creation of the object.</p>
        </emu-note>


<emu-note>
          <p>The object that may be created in step 6.a.ii is not accessible outside of the above algorithm and the ordinary object [[Set]] internal method. An implementation might choose to avoid the actual creation of that object.</p>
        </emu-note>


<emu-note>
        <p>Given the above definition of ToUint32:</p>
        <ul>
          <li>
            Step 6 is the only difference between ToUint32 and ToInt32.
          </li>
          <li>
            The ToUint32 abstract operation is idempotent: if applied to a result that it produced, the second application leaves that value unchanged.
          </li>
          <li>
            <emu-formula>ToUint32(ToInt32(_x_))</emu-formula> is equal to <emu-formula>ToUint32(_x_)</emu-formula> for all values of _x_. (It is to preserve this latter property that *+&infin;* and *-&infin;* are mapped to *+0*.)
          </li>
          <li>
            ToUint32 maps *-0* to *+0*.
          </li>
        </ul>
      </emu-note>


<emu-note>
        <p>Given the above definition of ToUint16:</p>
        <ul>
          <li>
            The substitution of 2<sup>16</sup> for 2<sup>32</sup> in step 5 is the only difference between ToUint32 and ToUint16.
          </li>
          <li>
            ToUint16 maps *-0* to *+0*.
          </li>
        </ul>
      </emu-note>


<emu-note>
          <p>The following observations may be useful as guidelines for implementations, but are not part of the normative requirements of this Standard:</p>
          <ul>
            <li>
              If x is any Number value other than *-0*, then ToNumber(ToString(x)) is exactly the same Number value as x.
            </li>
            <li>
              The least significant digit of s is not always uniquely determined by the requirements listed in step 5.
            </li>
          </ul>
        </emu-note>


<emu-note>
          <p>For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step 5 be used as a guideline:</p>
          <emu-alg>
            5. Otherwise, let _n_, _k_, and _s_ be integers such that _k_ &ge; 1, 10<sup>_k_-1</sup> &le; _s_ &lt; 10<sup>_k_</sup>, the Number value for _s_ &times; 10<sup>_n_-_k_</sup> is _m_, and _k_ is as small as possible. If there are multiple possibilities for _s_, choose the value of _s_ for which _s_ &times; 10<sup>_n_-_k_</sup> is closest in value to _m_. If there are two such possible values of _s_, choose the one that is even. Note that _k_ is the number of digits in the decimal representation of _s_ and that _s_ is not divisible by 10.
          </emu-alg>
        </emu-note>


<emu-note>
        <p>Step 5 differs from step 11 in the algorithm for the addition operator `+` (<emu-xref href="#sec-addition-operator-plus"></emu-xref>) in using &ldquo;and&rdquo; instead of &ldquo;or&rdquo;.</p>
      </emu-note>


<emu-note>
        <p>Step 5 will only be reached if _target_ is a non-standard exotic function object that does not have a [[Realm]] internal slot.</p>
      </emu-note>


<emu-note>
            <p>An example of ECMAScript code that results in a missing binding at step 2 is:</p>
            <pre>
function f(){eval("var x; x = (delete x, 0);")}
</pre>
</emu-note>


<emu-note>
          <p>Global function declarations are always represented as own properties of the global object. If possible, an existing own property is reconfigured to have a standard set of attribute values. Steps 10-12 are equivalent to what calling the InitializeBinding concrete method would do and if _globalObject_ is a Proxy will produce the same sequence of Proxy trap calls.</p>
        </emu-note>


<emu-note>
        <p>The loop in step 2 will always terminate because the list of environments always ends with the global environment which has a `this` binding.</p>
      </emu-note>


<emu-note>
        <p>The loop in step 8 guarantees that there will be no circularities in any prototype chain that only includes objects that use the ordinary object definitions for [[GetPrototypeOf]] and [[SetPrototypeOf]].</p>
      </emu-note>


<emu-note>
          <p>Step 8.b allows any field of _Desc_ to be different from the corresponding field of _current_ if _current_'s [[Configurable]] field is *true*. This even permits changing the [[Value]] of a property whose [[Writable]] attribute is *false*. This is allowed because a *true* [[Configurable]] attribute would permit an equivalent sequence of calls where [[Writable]] is first set to *true*, a new [[Value]] is set, and then [[Writable]] is set to *false*.</p>
        </emu-note>


<emu-note>
        <p>When _calleeContext_ is removed from the execution context stack in step 8 it must not be destroyed if it is suspended and retained for later resumption by an accessible generator object.</p>
      </emu-note>


<emu-note>
          <p>In steps 3 and 5, if <emu-formula>_Desc_.[[Value]]</emu-formula> is an object then its `valueOf` method is called twice. This is legacy behaviour that was specified with this effect starting with the 2<sup>nd</sup> Edition of this specification.</p>
        </emu-note>


<emu-note>
          <p>No hint is provided in the calls to ToPrimitive in steps 7 and 9. All standard objects except Date objects handle the absence of a hint as if the hint Number were given; Date objects handle the absence of a hint as if the hint String were given. Exotic objects may handle the absence of a hint in some other manner.</p>
        </emu-note>


<emu-note>
          <p>Step 11 differs from step 5 of the Abstract Relational Comparison algorithm (<emu-xref href="#sec-abstract-relational-comparison"></emu-xref>), by using the logical-or operation instead of the logical-and operation.</p>
        </emu-note>


<emu-note>
        <p>Steps 5 and 6 provide compatibility with previous editions of ECMAScript that did not use a @@hasInstance method to define the `instanceof` operator semantics. If a function object does not define or inherit @@hasInstance it uses the default `instanceof` semantics.</p>
      </emu-note>


<emu-note>
        <p>When an assignment occurs within strict mode code, it is an runtime error if _lref_ in step 1.f of the first algorithm or step 9 of the second algorithm it is an unresolvable reference. If it is, a *ReferenceError* exception is thrown. The |LeftHandSideExpression| also may not be a reference to a data property with the attribute value <emu-formula>{[[Writable]]:*false*}</emu-formula>, to an accessor property with the attribute value <emu-formula>{[[Set]]:*undefined*}</emu-formula>, nor to a non-existent property of an object for which the IsExtensible predicate returns the value *false*. In these cases a *TypeError* exception is thrown.</p>
      </emu-note>


<emu-note>
          <p>If a |VariableDeclaration| is nested within a with statement and the |BindingIdentifier| in the |VariableDeclaration| is the same as a property name of the binding object of the with statement's object Environment Record, then step 8 will assign _value_ to the property instead of assigning to the VariableEnvironment binding of the |Identifier|.</p>
        </emu-note>


<emu-note>
        <p>An |ArrowFunction| does not define local bindings for `arguments`, `super`, `this`, or `new.target`. Any reference to `arguments`, `super`, `this`, or `new.target` within an |ArrowFunction| must resolve to a binding in a lexically enclosing environment. Typically this will be the Function Environment of an immediately enclosing function. Even though an |ArrowFunction| may contain references to `super`, the function object created in step 4 is not made into a method by performing MakeMethod. An |ArrowFunction| that references `super` is always contained within a non-|ArrowFunction| and the necessary state to implement `super` is accessible via the _scope_ that is captured by the function object of the |ArrowFunction|.</p>
      </emu-note>


<emu-note>
          <p>The ordering of steps 1 and 3 is chosen to ensure that any exception that would have been thrown by step 1 in previous editions of this specification will continue to be thrown even if the *this* value is *undefined* or *null*.</p>
        </emu-note>


<emu-note>
          <p>The ordering of steps 1 and 2 preserves the behaviour specified by previous editions of this specification for the case where _V_ is not an object and the *this* value is *undefined* or *null*.</p>
        </emu-note>


<emu-note>
          <p>The ordering of steps 1 and 3 is chosen to ensure that any exception that would have been thrown by step 1 in previous editions of this specification will continue to be thrown even if the *this* value is *undefined* or *null*.</p>
        </emu-note>


<emu-note>
          <p>If _func_ is an arrow function or a bound function then the _thisArg_ will be ignored by the function [[Call]] in step 6.</p>
        </emu-note>


<emu-note>
          <p>If _func_ is an arrow function or a bound function then the _thisArg_ will be ignored by the function [[Call]] in step 5.</p>
        </emu-note>


<emu-note>
          <p>For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step 12.b.i be used as a guideline:</p>
          <emu-alg type="i">
            1. Let _e_, _n_, and _f_ be integers such that _f_ &ge; 0, 10<sup>_f_</sup> &le; n &lt; 10<sup>_f_+1</sup>, the Number value for n &times; 10<sup>_e_-_f_</sup> is x, and _f_ is as small as possible. If there are multiple possibilities for _n_, choose the value of _n_ for which _n_ &times; 10<sup>_e_-_f_</sup> is closest in value to _x_. If there are two such possible values of _n_, choose the one that is even.
          </emu-alg>
        </emu-note>


<emu-note>
          <p>The point of step 3 is that an implementation is permitted a choice of internal representations of time values, for example as a 64-bit signed integer or as a 64-bit floating-point value. Depending on the implementation, this internal representation may or may not distinguish *-0* and *+0*.</p>
        </emu-note>


<emu-note>
  <p>Step 5 of the RepeatMatcher clears |Atom|'s captures each time |Atom| is repeated. We can see its behaviour in the regular expression</p>
  <pre>
/(z)((a+)?(b+)?(c))*/.exec("zaacbbbcac")
</pre>
<p>which returns the array</p>
<pre>
["zaacbbbcac", "z", "ac", "a", undefined, "c"]
</pre>
<p>and not</p>
<pre>
["zaacbbbcac", "z", "ac", "a", "bbb", "c"]
</pre>
<p>because each iteration of the outermost `*` clears all captured Strings contained in the quantified |Atom|, which in this case includes capture Strings numbered 2, 3, 4, and 5.</p>
</emu-note>


<emu-note>
  <p>Step 1 of the RepeatMatcher's _d_ closure states that, once the minimum number of repetitions has been satisfied, any more expansions of |Atom| that match the empty character sequence are not considered for further repetitions. This prevents the regular expression engine from falling into an infinite loop on patterns such as:</p>
  <pre>
/(a*)*/.exec("b")
</pre>
<p>or the slightly more complicated:</p>
<pre>
/(a*)b\1+/.exec("baaaac")
</pre>
<p>which returns the array</p>
<pre>
["b", ""]
</pre>
</emu-note>


<emu-note>
          <p>The explicit setting of the `length` property in step 8 is necessary to ensure that its value is correct in situations where the trailing elements of the result Array are not present.</p>
        </emu-note>


<emu-note>
          <p>The explicit setting of the `length` property of the result Array in step 16 is necessary to ensure that its value is correct in situations where the trailing elements of the result Array are not present.</p>
        </emu-note>


<emu-note>
            <p>Method calls performed by the ToString abstract operations in steps 5 and 7 have the potential to cause SortCompare to not behave as a consistent comparison function.</p>
          </emu-note>


<emu-note>
          <p>The explicit setting of the `length` property of the result Array in step 24 is necessary to ensure that its value is correct in situations where its trailing elements are not present.</p>
        </emu-note>


<emu-note>
        <p>The syntax of a valid JSON text is a subset of the ECMAScript |PrimaryExpression| syntax. Hence a valid JSON text is also a valid |PrimaryExpression|. Step 3 above verifies that _JText_ conforms to that subset. When _scriptText_ is parsed and evaluated as a |Script| the result will be either a String, Number, Boolean, or Null primitive value or an Object defined as if by an |ArrayLiteral| or |ObjectLiteral|.</p>
      </emu-note>