remove built-in async function infrastructure from this proposal

[michaelficarra]

See tc39/proposal-iterator-helpers#245 and tc39/ecma262#2942. This will align our efforts and allow reviewers to focus on the actual content of this proposal.

[bakkot]

Probably worth replacing this with a stub pointing to the PR? Or mentioning it in an editor's note, say.

Also, this proposal doesn't use the notion of a "built-in async function" - it's calling AsyncFunctionStart itself. Withhttps://github.com/tc39/ecma262/pull/2942 it could (and probably should) use that machinery, though.

[michaelficarra]

I'll leave it up to the proposal authors to make further changes like that. Either in this PR or as a follow-up is fine by me.

[js-choi]

I will take a look at adding a stub soon. Apologies for the delay.

[ljharb]

@js-choi ping, it's been almost a year

[js-choi]

@ljharb: Thanks for the ping. Apologies for dropping this task.

I am fine with this pull request’s removal of the AsyncFunction Objects section from the spec in favor of depending on tc39/ecma262#2942. That other pull request adds many things, but the important part for this proposal’s current spec is that it allows AsyncBlockStart to take an abstract closure as an argument.

I agree with @bakkot that adding a note referring to tc39/ecma262#2942 would be good, and I will add a note after merging this pull request now.

It’s also true that the Array.fromAsync spec does not currently use all of the new machinery that tc39/ecma262#2942 adds. It just uses its enhancement of AsyncFunctionStart. What other machinery should Array.fromAsync use? Would it be redefined as a “built-in async function object”? I also note that tc39/ecma262#2942 (comment) suggests that the final form of tc39/ecma262#2942 is still not completely settled.
Anyways, I’ll open a separate issue for that.