Closed bathos closed 1 year ago
(Hm, are those “fixup” commits expected? I hadn’t noticed initially — It looks like they were triggered automatically.)
I intend for the "Yes" cells to be blank, to avoid the unnecessary boilerplate.
I intend for the "Yes" cells to be blank, to avoid the unnecessary boilerplate.
Should the column be flipped then — “Directly Accessible to ECMAScript code” → “Inaccessible to ECMAScript code”? No strong feeling on this, but to me, empty cells implicitly meaning “No” seems more intuitive than empty cells implicitly meaning “Yes”.
Sure, that works too - I just mirrored the phrasing in existing prose.
The new “Directly Accessible to ECMAScript code” column in the Well-Known Intrinsic Objects table should seemingly have No for two entries, %ForInIteratorPrototype% (already in spec text) but also %AsyncFromSyncIteratorPrototype%:
“Async-from-Sync Iterator instances are not directly observable from ECMAScript code.”
I’m guessing the ultimate PR against ECMA-262 would also include every other row sprouting a
<td>Yes</td>
cell, but that those differences have been omitted intentionally for now in the interest of focus. However because there are only two rows for which No would be the value presently, including both seems to make the scope of the change to the table clearer.