14.4.14 Runtime Semantics: Evaluation
YieldExpression : yield * AssignmentExpression
Step 6.b.iv.4 is unreachable because the algorithm always returns at 6.b.iv.3:
Change 6.b.iv.2 from:
> Let closeResult be IteratorClose(iterator, received).
to:
> Let closeResult be IteratorClose(iterator, Completion{[[type]]: normal, [[value]]: received.[[value]], [[target]]:empty}).
fixed in rev37 editor's draft
Since IteratorClose is always going to produce an abrupt completion all that is needed is a 'Return' of the result of 6.b.1v.2
The only time IteratorClose will return something other than /received/ is if its GetMethod call fails. In that case, it's fine to just propagate whatever exception that produced.
(In reply to Allen Wirfs-Brock from comment #1)
> Since IteratorClose is always going to produce an abrupt completion all that
> is needed is a 'Return' of the result of 6.b.1v.2
That means the "protocol violation" proposal from [1] is dropped?
[1] https://esdiscuss.org/topic/a-weird-yield-edge-case#content-6
ah, right!
ok, your fix does it. Except that I don't see any point in passing received.[[value]] into IteratorClose via the constructed completion record
(In reply to Allen Wirfs-Brock from comment #3)
> ok, your fix does it. Except that I don't see any point in passing
> received.[[value]] into IteratorClose via the constructed completion record
Hmm, I've got no idea why I did that...
In Rev37