archives

« Bugzilla Issues Index

#3778 — 25.4.4.1.1 PerformPromiseAll: Change to full completion record access ?


25.4.4.1.1 PerformPromiseAll( iterator, constructor, resultCapability) Abstract Operation

Step 7.c.ii.3.

> , return NormalCompletion(resolveResult).


Implicit access to the [[value]] field of completion records is typically only used for normal completions. For abrupt completions the `.[[value]]` syntax is used instead.

Maybe change to `NormalCompletion(resolveResult.[[value]])` ?


Also cc'ed Domenic to check the new semantic for PerformPromiseAll when the call to [[Resolve]] in step 7.c.ii.2 results in an abrupt completion.


Test case for the changed semantics:
---
function P(executor) {
executor(() => { throw "hi!" }, () => {});
}
console.log(Promise.all.call(P, [])); // Prints "hi!".
---


Yes, this does look suspicious, and against the original design of Promise.all. I think that step should just be ReturnIfAbrupt(resolveResult). Allen, any reason for this change, or was it just a refactoring issue?


(In reply to Domenic Denicola from comment #2)
> Yes, this does look suspicious, and against the original design of
> Promise.all. I think that step should just be ReturnIfAbrupt(resolveResult).
> Allen, any reason for this change, or was it just a refactoring issue?

What this all trying to do is avoid the IteratorClose call in 25.4.4.1 step 11.a when an exception occurs in 7.c.ii.3 (after the iteral is has been drained).

The normal completion causes steps 11.a and 11.b to be skipped.

And the value return in step 12 is the original resolveResult abrupt completion from 7.c.ii.3 -- effectively the same as the ReturnIfAbrupt that used to there

Admittedly this is playing fast and loose with completion record conventions, but that it almost does what I want...


Oh, I think I see... it's a normal completion whose .[[value]] is an abrupt completion?!? So comment #1's test case isn't quite correct?

Sneaky.

(I still don't understand why iterator.close() isn't called at the end of every for-on loop, but instead only for abrupt completions... but that's my problem.)


(In reply to Allen Wirfs-Brock from comment #3)
> Admittedly this is playing fast and loose with completion record
> conventions, but that it almost does what I want...

Just like Domenic said, that's sneaky! Fortunately completion records don't allow this construction. ([[value]] is restricted to ECMAScript language values or empty.)


fixed in rev33 editor's draft

Ok, took away the cleverness (never a good idea in a specification) and made it explicit


fixed in rev33