Macros which affect control flow should be visible at callsite

[bakkot]

IfAbruptRejectPromise is used like a macro, but it returns from the caller in one of its branches. (IfAbruptCloseIterator in https://github.com/tc39/ecma262/pull/2113 will have the same problem.) That's confusing for readers.

We should distinguish these calls somehow. Maybe they could be kebab-case, so they don't look like AO invocations?

[bakkot]

I'm also partial to rust's macro! syntax, though @michaelficarra said he'd prefer something without a new sigil.

[devsnek]

Is there a reason you're calling out those two specifically? ReturnIfAbrupt has the same behavior for example.

[bakkot]

ReturnIfAbrupt has the same issue, yes.

[michaelficarra]

I'm partial to special prose forms like we do with substrings.

[bakkot]

@michaelficarra do you have a prose form in mind for, e.g., IfAbruptRejectPromise?

[syg]

"Perform the expansion of", maybe?

[michaelficarra]

@syg I like the idea of a special form for macro application, though I was referring to per-macro special forms above. So for IfAbruptRejectPromise, something like Account for abruptness of _value_ with rejection of _capability_..

[syg]

Oh I see, you were thinking of the thing HTML does. I'm fine with either ! or special prose forms so long as it's all autolinked, which I'm sure it will be. The auto-linking of special prose forms will be more finicky, though.

[ExE-Boss]

See also:

• https://github.com/tc39/ecma262/issues/2384