Skip to content

Commit

Permalink
Editorial: Eliminate 'bare' uses of "completion"
Browse files Browse the repository at this point in the history
(2 uses of "completion" and 8 uses of "completion value")
  • Loading branch information
jmdyck committed Mar 4, 2022
1 parent cbd5493 commit f0342b6
Showing 1 changed file with 7 additions and 9 deletions.
16 changes: 7 additions & 9 deletions spec.html
Original file line number Diff line number Diff line change
Expand Up @@ -4000,7 +4000,7 @@ <h1>The Completion Record Specification Type</h1>
<li><dfn variants="abrupt completions">abrupt completion</dfn> refers to any Completion Record with a [[Type]] value other than ~normal~.</li>
<li>a <dfn variants="normal completions containing">normal completion containing</dfn> some type of value refers to a normal completion that has a value of that type in its [[Value]] field.</li>
</ul>
<p>Callable objects that are defined in this specification only return a normal completion or a throw completion. Returning any other kind of completion is considered an editorial error.</p>
<p>Callable objects that are defined in this specification only return a normal completion or a throw completion. Returning any other kind of Completion Record is considered an editorial error.</p>
<p>Implementation-defined callable objects must return either a normal completion or a throw completion.</p>

<emu-clause id="await" oldids="await-fulfilled,await-rejected" aoid="Await">
Expand Down Expand Up @@ -27830,9 +27830,7 @@ <h1>
<ul>
<li>At some future time, the host environment must perform FinishDynamicImport(_referencingScriptOrModule_, _specifier_, _promiseCapability_, _promise_), where _promise_ is a Promise resolved with *undefined*.</li>

<li>Any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments _referencingScriptOrModule_ and _specifier_, must complete normally.</li>

<li>The completion value of any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments _referencingScriptOrModule_ and _specifier_, must be a module which has already been evaluated, i.e. whose Evaluate concrete method has already been called and returned a normal completion.</li>
<li>Any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments _referencingScriptOrModule_ and _specifier_, must return a normal completion containing a module which has already been evaluated, i.e. whose Evaluate concrete method has already been called and returned a normal completion.</li>
</ul>
</dd>

Expand Down Expand Up @@ -37634,7 +37632,7 @@ <h1>Array.prototype.sort ( _comparefn_ )</h1>
1. Append _kValue_ to _items_.
1. Set _k_ to _k_ + 1.
1. Let _itemCount_ be the number of elements in _items_.
1. [id="step-array-sort"] Sort _items_ using an implementation-defined sequence of calls to SortCompare. If any such call returns an abrupt completion, stop before performing any further calls to SortCompare or steps in this algorithm and return that completion.
1. [id="step-array-sort"] Sort _items_ using an implementation-defined sequence of calls to SortCompare. If any such call returns an abrupt completion, stop before performing any further calls to SortCompare or steps in this algorithm and return that Completion Record.
1. Let _j_ be 0.
1. Repeat, while _j_ &lt; _itemCount_,
1. Perform ? Set(_obj_, ! ToString(𝔽(_j_)), _items_[_j_], *true*).
Expand Down Expand Up @@ -40420,7 +40418,7 @@ <h1>Notation</h1>
<p>To aid verifying that a read-modify-write modification function's algorithm steps constitute a pure, mathematical function, the following editorial conventions are recommended:</p>
<ul>
<li>They do not access, directly or transitively via invoked abstract operations and abstract closures, any language or specification values except their parameters and captured values.</li>
<li>They do not return completion values.</li>
<li>They do not return Completion Records.</li>
</ul>
</emu-note>
</emu-clause>
Expand Down Expand Up @@ -45311,7 +45309,7 @@ <h1>
1. Push _asyncContext_ onto the execution context stack; _asyncContext_ is now the running execution context.
1. <emu-meta effects="user-code">Resume the suspended evaluation of _asyncContext_</emu-meta>. Let _result_ be the value returned by the resumed computation.
1. Assert: When we return here, _asyncContext_ has already been removed from the execution context stack and _runningContext_ is the currently running execution context.
1. Assert: _result_ is a normal completion with a value of ~unused~. The possible sources of completion values are Await or, if the async function doesn't await anything, step <emu-xref href="#step-asyncblockstart-return-undefined"></emu-xref> above.
1. Assert: _result_ is a normal completion with a value of ~unused~. The possible sources of this value are Await or, if the async function doesn't await anything, step <emu-xref href="#step-asyncblockstart-return-undefined"></emu-xref> above.
1. Return ~unused~.
</emu-alg>
</emu-clause>
Expand Down Expand Up @@ -47823,7 +47821,7 @@ <h1>Additions and Changes That Introduce Incompatibilities with Prior Editions</
<p><emu-xref href="#sec-assignment-operators-static-semantics-early-errors"></emu-xref>: In ECMAScript 2015, strict mode code containing an assignment to an immutable binding such as the function name of a |FunctionExpression| does not produce an early error. Instead it produces a runtime error.</p>
<p><emu-xref href="#sec-block"></emu-xref>: In ECMAScript 2015, a |StatementList| beginning with the token let followed by the input elements |LineTerminator| then |Identifier| is the start of a |LexicalDeclaration|. In previous editions, automatic semicolon insertion would always insert a semicolon before the |Identifier| input element.</p>
<p><emu-xref href="#sec-expression-statement"></emu-xref>: In ECMAScript 2015, a |StatementListItem| beginning with the token `let` followed by the token `[` is the start of a |LexicalDeclaration|. In previous editions such a sequence would be the start of an |ExpressionStatement|.</p>
<p><emu-xref href="#sec-if-statement-runtime-semantics-evaluation"></emu-xref>: In ECMAScript 2015, the normal completion value of an |IfStatement| is never the value ~empty~. If no |Statement| part is evaluated or if the evaluated |Statement| part produces a normal completion whose value is ~empty~, the completion value of the |IfStatement| is *undefined*.</p>
<p><emu-xref href="#sec-if-statement-runtime-semantics-evaluation"></emu-xref>: In ECMAScript 2015, the normal result of an |IfStatement| is never the value ~empty~. If no |Statement| part is evaluated or if the evaluated |Statement| part produces a normal completion containing ~empty~, the result of the |IfStatement| is *undefined*.</p>
<p><emu-xref href="#sec-iteration-statements"></emu-xref>: In ECMAScript 2015, if the `(` token of a for statement is immediately followed by the token sequence `let [` then the `let` is treated as the start of a |LexicalDeclaration|. In previous editions such a token sequence would be the start of an |Expression|.</p>
<p><emu-xref href="#sec-iteration-statements"></emu-xref>: In ECMAScript 2015, if the ( token of a for-in statement is immediately followed by the token sequence `let [` then the `let` is treated as the start of a |ForDeclaration|. In previous editions such a token sequence would be the start of an |LeftHandSideExpression|.</p>
<p><emu-xref href="#sec-iteration-statements"></emu-xref>: Prior to ECMAScript 2015, an initialization expression could appear as part of the |VariableDeclaration| that precedes the `in` keyword. In ECMAScript 2015, the |ForBinding| in that same position does not allow the occurrence of such an initializer. In ECMAScript 2017, such an initializer is permitted only in non-strict code.</p>
Expand All @@ -47832,7 +47830,7 @@ <h1>Additions and Changes That Introduce Incompatibilities with Prior Editions</
<p><emu-xref href="#sec-switch-statement-runtime-semantics-evaluation"></emu-xref>: In ECMAScript 2015, the result of evaluating a |SwitchStatement| is never a normal completion whose [[Value]] is ~empty~. If evaluation of the |CaseBlock| part of a |SwitchStatement| produces a normal completion whose [[Value]] is ~empty~, the result of evaluating the |SwitchStatement| is a normal completion whose [[Value]] is *undefined*.</p>
<p><emu-xref href="#sec-try-statement"></emu-xref>: In ECMAScript 2015, it is an early error for a |Catch| clause to contain a `var` declaration for the same |Identifier| that appears as the |Catch| clause parameter. In previous editions, such a variable declaration would be instantiated in the enclosing variable environment but the declaration's |Initializer| value would be assigned to the |Catch| parameter.</p>
<p><emu-xref href="#sec-try-statement"></emu-xref>, <emu-xref href="#sec-evaldeclarationinstantiation"></emu-xref>: In ECMAScript 2015, a runtime *SyntaxError* is thrown if a |Catch| clause evaluates a non-strict direct `eval` whose eval code includes a `var` or `FunctionDeclaration` declaration that binds the same |Identifier| that appears as the |Catch| clause parameter.</p>
<p><emu-xref href="#sec-try-statement-runtime-semantics-evaluation"></emu-xref>: In ECMAScript 2015, the completion value of a |TryStatement| is never the value ~empty~. If the |Block| part of a |TryStatement| evaluates to a normal completion whose value is ~empty~, the completion value of the |TryStatement| is *undefined*. If the |Block| part of a |TryStatement| evaluates to a throw completion and it has a |Catch| part that evaluates to a normal completion whose value is ~empty~, the completion value of the |TryStatement| is *undefined* if there is no |Finally| clause or if its |Finally| clause evaluates to an ~empty~ normal completion.</p>
<p><emu-xref href="#sec-try-statement-runtime-semantics-evaluation"></emu-xref>: In ECMAScript 2015, the result of a |TryStatement| is never the value ~empty~. If the |Block| part of a |TryStatement| evaluates to a normal completion containing ~empty~, the result of the |TryStatement| is *undefined*. If the |Block| part of a |TryStatement| evaluates to a throw completion and it has a |Catch| part that evaluates to a normal completion containing ~empty~, the result of the |TryStatement| is *undefined* if there is no |Finally| clause or if its |Finally| clause evaluates to an ~empty~ normal completion.</p>
<p><emu-xref href="#sec-runtime-semantics-methoddefinitionevaluation"></emu-xref> In ECMAScript 2015, the function objects that are created as the values of the [[Get]] or [[Set]] attribute of accessor properties in an |ObjectLiteral| are not constructor functions and they do not have a *"prototype"* own property. In the previous edition, they were constructors and had a *"prototype"* property.</p>
<p><emu-xref href="#sec-object.freeze"></emu-xref>: In ECMAScript 2015, if the argument to `Object.freeze` is not an object it is treated as if it was a non-extensible ordinary object with no own properties. In the previous edition, a non-object argument always causes a *TypeError* to be thrown.</p>
<p><emu-xref href="#sec-object.getownpropertydescriptor"></emu-xref>: In ECMAScript 2015, if the argument to `Object.getOwnPropertyDescriptor` is not an object an attempt is made to coerce the argument using ToObject. If the coercion is successful the result is used in place of the original argument value. In the previous edition, a non-object argument always causes a *TypeError* to be thrown.</p>
Expand Down

0 comments on commit f0342b6

Please sign in to comment.