whatwg
"Abort when" vs "abort these steps"
It feels like these definitions clash.
"Abort these steps" is more like return, but can be used when in parallel.
"Abort when" is more like break.
I'm not sure what the best solution is here. Either:
Replace "abort these steps" with "return". This might be confusing when in parallel. Will it be clear that "return" only ends the in parallel steps?
Replace "abort when" with "break when". This feels like it fits the behavior more accurately, as steps following the "abort when" block will run after breaking.
No solutions, but...
See #255 for my attempt at clarifying when "abort these steps" makes sense, although it's a bit stalled.
"Break when" might be confusing if used inside an actual loop where "break" is defined by Infra to mean something already.
"Break" could be redefined:
Within an iteration, "break" will skip over any remaining steps in an iteration, and skip over any remaining items as well, stopping the iteration. Within any other block of steps, "break" will skip the remaining steps.
This feels similar to how it behaves in JavaScript.
Maybe we have a better definition of "block of steps". I mean the direct children of the <ol>.
Isn't an "abort when" block really just a hidden loop wherein you're evaluating whether the abort condition is met in between the steps of the algorithm you're executing? (The comment suggests that the check needn't be between steps, but it has a caveat that the abort cannot happen when a value is mutated; in the example, the calculation and the mutation are really two separate steps artificially combined by "and", so I call shenanigans on that.)
Separately, throwing some more possible terms out there to get the juices flowing: halt, stop, last (as in "this is the last step", from Perl), exit. Might also consider more extensive use of throwing exceptions.
Isn't an "abort when" block really just a hidden loop wherein you're evaluating whether the abort condition is met in between the steps of the algorithm you're executing?
Yep. But if the condition becomes true, it only skips the rest of its inner steps, which is different to "abort these steps", which cancels the whole synchronously executing algorithm.
Since Domenic closed PR #255, let me copy my comment here:
More broadly, an algorithm is a set of steps. Just because you sometimes pass a set of steps into another set of steps doesn't make either set of steps any less of an algorithm. So you might want to differentiate between an intentionally-incomplete set of steps (like some sort of mix-in or partial function) from a nested-but-complete set of steps (like a direct function call or a callback argument), and then the language of how to exit the set of steps (either prematurely or at the end) might fall out from that (I hope).