Editorial: remove ReturnIfAbrupt and specify ! and ? directly

[bakkot]

The ? and ! shorthands have long been under-specified, as discussed in #1570, this thread, etc. Also, as of recent efforts (#1571, #2744, #2924, #3268, etc) there are no longer any uses of ReturnIfAbrupt except to define ?. So remove ReturnIfAbrupt. Instead, as proposed in this comment, specify evaluation order as a (handwavy, but hopefully clear) rewrite rule, and then define ? and ! directly, with nontrivial cases handled by first applying the rewrite rule.

I checked ECMA-402, HTML, streams, and Wasm, and found no uses of ReturnIfAbrupt. There are still some uses in proposals, but whatever.

Closes #1570 and #1573.

[github-actions]

The rendered spec for this PR is available at https://tc39.es/ecma262/pr/3705.

[michaelficarra]

Can you draft a change to the Editorial Conventions document about not relying on this evaluation order under normal circumstances and post it here?

[bakkot]

Sure, how about:

Avoid relying on evaluation order of expressions within algorithm steps. While this is formally defined in [link to section], prefer separating evaluation of subexpressions into their own steps in cases where this would matter.

[michaelficarra]

The excessive hand-waviness is making me a little uncomfortable. It's not 100% clear which parts of Let _result_ be ? _record_ and Let _result_ be ! _record_ are essential and which are nonessential. I don't think we need to go the full rewrite approach I took in my PR, but maybe it'd be clearer if we included a second example for each using, e.g., Perform with an AO invocation. And we should say explicitly that it's not limited to these exact forms, but any steps using ? and ! get a corresponding transform.

[bakkot]

I can definitely add another example. I don't want to use Perform specifically because the rewrite exposes the fact that Perform doesn't actually mean anything, which isn't something I want to have to explain.

And we should say explicitly that it's not limited to these exact forms, but any steps using ? and ! get a corresponding transform.

That's the intention of the bit which says

When ? or ! is used in any other context, first apply the rewrite given in <emu-xref href="#sec-evaluation-order" title></emu-xref>, then apply this rule.

I don't know what you're asking for that isn't already covered by this sentence.

[michaelficarra]

which isn't something I want to have to explain.

No explanation needed, Perform is on both sides of the rewrite.

That's the intention of the bit which says

To me, the only thing that sentence is trying to communicate is that algorithm steps that do more than one thing should be treated as a series of algorithm steps that accomplishes the same thing when applying this transform. It doesn't say anything about steps not looking literally like Let followed by an alias name followed by be ?/be ! followed by another alias name. I want it to be clear that it also applies to steps that, after being broken down, look like Perform ... or Set ... and where the CR is not an alias but is being returned from an AO invocation. That sort of thing. I think the hand-wavey explanation would be sufficient if we both add another example or two and have a sentence that tries to state that explicitly.

[bakkot]

No explanation needed, Perform is on both sides of the rewrite.

The problem is that after the rewrite there's a step which reads Perform _variable_, which looks silly.

To me, the only thing that sentence is trying to communicate is that algorithm steps that do more than one thing should be treated as a series of algorithm steps that accomplishes the same thing when applying this transform. It doesn't say anything about steps not looking literally like Let followed by an alias name followed by be ?/be ! followed by another alias name.

Applying the specific transform described in the Evaluation Order section will ultimately result in a step which looks literally like Let followed by an alias name followed by be ?/be ! followed by another alias name. That's the whole point of having the Evaluation Order section.