tc39 / ecma262

Status, process, and documents for ECMA-262
https://tc39.es/ecma262/
Other
14.9k stars 1.27k forks source link

Macros which affect control flow should be visible at callsite #2498

Open bakkot opened 2 years ago

bakkot commented 2 years ago

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 commented 2 years ago

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

devsnek commented 2 years ago

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

bakkot commented 2 years ago

ReturnIfAbrupt has the same issue, yes.

michaelficarra commented 2 years ago

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

bakkot commented 2 years ago

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

syg commented 2 years ago

"Perform the expansion of", maybe?

michaelficarra commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

See also: