Better iterator close

[bakkot]

EDIT: this is slightly wrong and will need to be tweaked. Don't review yet.

Fixes #3072.

Open to other names for the new AOs. IteratorCloseSuppressingExceptions would also work.

I didn't add an async version since we only touch async iterators in a couple places.

"abrupt completion" isn't synonymous with "throw completion", so the use in IfAbruptCloseIterator can't be replaced as currently written. As it happens, all of the callsites of IfAbruptCloseIterator currently in the spec can only pass it throw completions or normal completions, so we could change it to "IfThrowCloseIterator" and then change the implementation. But the iterator helpers proposal introduces some uses of IfAbruptCloseIterator which can get passed return completions, so we'd need to do something else there. I'm inclined to leave it alone.

I went a little further than #3072 suggests, in the third commit, which I think ends up in a cleaner place. I'm fine leaving it at the second commit though.

Note that this will require changes in 402, Temporal, and Iterator Helpers (if we include the third commit), which I'll do after we land this.

[jmdyck]

Delete the .[[Value]] here, because the previous line unwrapped it.

[jmdyck]

I don't think you need IteratorCloseForThrow. Anywhere that says
Perform IteratorCloseForThrow(...),
you can just say
Perform IteratorClose(...)
with the same semantics.

[jmdyck]

Is _status_ necessarily a throw completion here?

[bakkot]

Yes: IteratorDestructuringAssignmentEvaluation can only return a throw completion or a normal completion, so guarding on abruptness of its result suffices.

[jmdyck]

Yes: IteratorDestructuringAssignmentEvaluation can only return a throw completion or a normal completion,

So we should change its declared return-type?

[jmdyck]

Is _status_ necessarily a throw completion here?

[bakkot]

Yes: _status_ here can only arise from DestructuringAssignmentEvaluation, BindingInitialization, Evaluation of _lhs_ (which is either a LeftHandSideExpression, a ForBinding, a ForDeclaration, or a ForBinding; for each of these Evaluation to throw or normal completions), PutValue, ForDeclarationBindingInitialization, or InitializeReferencedBinding. And those all can only return a throw completion or a normal completion, so guarding on abruptness of `status suffices.

[jmdyck]

DestructuringAssignmentEvaluation, BindingInitialization, PutValue, ForDeclarationBindingInitialization, and InitializeReferencedBinding are all declared to return normal or abrupt. Can we change abrupt to throw for them?

And for the Evaluation of _lhs_, maybe when _lhsRef_ is abrupt, there could be an Assert that it's a throw completion.

[jmdyck]

(This reminded me of #2676 and #2676 (comment) in particular.)

[bakkot]

Ah jeez, you're right, I always forget about yield. These are wrong.

[bakkot]

I don't think you need IteratorCloseForThrow. Anywhere that says Perform IteratorCloseForThrow(...), you can just say Perform IteratorClose(...) with the same semantics.

By convention (enforced by ecmarkup) you can't call any completion-returning AO without either explicitly mentioning the fact that it returns a completion record (by wrapping with Completion) or unwrapping with either ? or !.

We could say Perform Completion(IteratorClose(...)), of course. But that's less clear than an explicit AO, I think.

[jmdyck]

By convention (enforced by ecmarkup) you can't call any completion-returning AO without either explicitly mentioning the fact that it returns a completion record (by wrapping with Completion) or unwrapping with either ? or !.

Okay.

We could say Perform Completion(IteratorClose(...)), of course. But that's less clear than an explicit AO, I think.

I think I'd prefer Perform Completion(IteratorClose(...)) over another AO.