archives

« Bugzilla Issues Index

#1315 — 11.1.4.1 + 15.5.4.14 + 15.10.4.14: making an assertion about the result of the previous step


In 11.1.4.1 "Array Literal",
under "Runtime Semantics: Array Accumulation",
each of rules 1, 3, and 5 has a pair of steps of the form:
-- Call the [[DefineOwnProperty]] internal method ...
-- Assert: the above call to [[DefineOwnProperty]] will
never return false or an abrupt completion value.

This wording smacks a little of the old "Result(N)" notation.
To be more explicit, I suggest changing these to:
-- Let 'created' be the result of calling the [[DefineOwnProperty]]
internal method ...
-- Assert: 'created' is true.


----

Similarly, 15.5.4.14 and 15.10.4.14 each has 4 pairs of steps of the form:
-- Call the [[DefineOwnProperty]] internal method ...
-- Assert: the previous step will never result in an abrupt completion.

and I suggest changing each to:
-- Let 'created' be the result of calling the [[DefineOwnProperty]]
internal method ...
-- Assert: 'created' is not an abrupt completion.


Also, in 9.3.11 "CreateArrayFromList (elements)"
steps 4.a and 4.b say:
a. Call CreateOwnDataProperty(...).
b. Assert: the call in step 4.a will never result in an abrupt completion.

I suggest:
a. Let 'created' be the result of CreateOwnDataProperty(...).
b. Assert: 'created' is not an abrupt completion.

--------

In 10.6 "Arguments Object",
in the algorithm for [[DefineOwnProperty]],
steps 6.b.i.1 and .2 say:
1. Assert: the follow Put call will always succeed because formal
parameters mapped by argument objects are always writable.
2. Call Put(...).

I suggest:
1. Let 'putStatus' be the result of Put(...).
2. Assert: 'putStatus' is true because formal parameters
mapped by argument objects are always writable.


fixed in rev 16 editor's draft


fixed in rev16 draft. July 15, 2013