Editorial: create closures using the standard, verbose ES pattern

[domenic]

Although I've filed an issue to make this easier (tc39/ecma262#933), in the meantime, to get this spec ready for advancement, it should really use the standard style for closures.

You can see some examples in e.g. https://tc39.github.io/proposal-async-iteration/#await

[domenic]

They should also be nested as sub-clauses underneath the Promise.prototype.finally clause, similar to how Promise.all works

[domenic]

This may also be required for the valueThunk/thrower "closures". Maybe @bterlson can comment (since his review is required anyway) as to whether we can let those slip by...

[ljharb]

The style I'm using now was in the spec until a recent Promise refactor; iow, it's how ES2015 worded it. The refactor wasn't about closure-styles; why wouldn't we be able to continue using that style prior to tc39/ecma262#933 being resolved?

(I'll definitely fix the nesting regardless)

[domenic]

There has never been anything in the spec that creates closures using the words "Return a function that takes one argument, value, and when invoked, performs the following steps:" and implicitly closes over variables in the algorithm (onFinally).

[ljharb]

I'm referring to ES2015, prior to my refactor - it definitely didn't have a closure, but used "equivalent to" language.

I can certainly change it to use the more verbose form that uses an internal slot instead of closure semantics to provide onFInally, it just seems strictly less valuable and readable than this proposal's current language.

[domenic]

I don't think consistency is strictly less valuable.