Editorial: Unify style of abrupt completion and non-LoopContinues result handling in ForIn/OfBodyEvaluation

[aapoalas]

A personal favourite of mine: the order of checking/comparing iterationKind and iteratorKind is different between two otherwise nearly identical blocks handling abrupt completions (exceptions) in the loop header binding, and handling non-loop-continuing results of the body evaluation.

The difference makes the two blocks really hard to compare, even though they're 100% the same except for the UpdateEmpty call.

[aapoalas]

@michaelficarra This doesn't have any effect on behaviour of source text evaluation. It's strictly only a reordering of a few lines.

[linusg]

I like it :)

[michaelficarra]

Ah I see, this is relying on the fact that there's no call site for iterationKind of ~enumerate~ and iteratorKind of ~async~. This could probably be stated explicitly somewhere.

[aapoalas]

Ah I see, this is relying on the fact that there's no call site for iterationKind of ~enumerate~ and iteratorKind of ~async~. This could probably be stated explicitly somewhere.

I can add asserts in the ~enumerate~ branch for iteratorKind being ~sync~ if you'd want?

[michaelficarra]

@aapoalas I had something else in mind #3475 (comment)