-
Notifications
You must be signed in to change notification settings - Fork 34
"built-in async function"s are underspecified #218
Comments
Should this be a consideration upon integration at stage 4? Not sure if this rigour is needed at stage 3. |
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. |
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 existingAsyncBlockStart
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").
The text was updated successfully, but these errors were encountered: