Skip to content
This repository has been archived by the owner on Oct 8, 2024. It is now read-only.

"built-in async function"s are underspecified #218

Closed
bakkot opened this issue Aug 11, 2022 · 3 comments · Fixed by #240
Closed

"built-in async function"s are underspecified #218

bakkot opened this issue Aug 11, 2022 · 3 comments · Fixed by #240
Labels
bug Something isn't working needs resolution

Comments

@bakkot
Copy link
Collaborator

bakkot commented Aug 11, 2022

The async versions of the consuming helpers - toArray, etc - are specified as "built-in async function"s. But I don't think we've ever actually said what that means anywhere.

The Array.fromAsync proposal extends the existing AsyncBlockStart to take an abstract closure, and specifies the new "async function" in that proposal in terms of that AO. Unfortunately that too is underspecified.

I think we should define "built-in async function" rigorously, probably as a new type of exotic object with custom [[Call]] and [[Construct]] behaviors (where the [[Construct]] behavior is just "throw a TypeError").

@michaelficarra
Copy link
Member

Should this be a consideration upon integration at stage 4? Not sure if this rigour is needed at stage 3.

@bakkot
Copy link
Collaborator Author

bakkot commented Aug 12, 2022

I think stage 3 warrants at least a sketch of the intended approach. I can try to write something up.

@rbuckton
Copy link

rbuckton commented Sep 7, 2022

I think stage 3 warrants at least a sketch of the intended approach. I can try to write something up.

I agree we need something. Stage 3's criteria is "complete specification text" and it's my understanding that the quality of the spec at Stage 3 should be such that any changes between stage 3 and 4 should be to address implementation concerns, editorial issues, things that were overlooked, etc. Missing an entire description of how these algorithm steps should even work seems like a glaring omission. There definitely should be something explaining how this should work, otherwise the algorithm steps should be written to use existing spec mechanics. It's probably fine if it's not perfect as long as the intention is clearly spelled out.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working needs resolution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants