The current spec misuses ~return~ completions. Those are use for propagating a literal syntactic return in an ES function up through any intermediate syntax (which is handled by the ? macro) to the [[Call]] AO which invoked the function, where it is unwrapped into a normal completion (in step 10.2.1 of that algorithm).
Built-in functions do not need to deal with that propagation, so they can (and do) just return a normal completion holding the value in question directly. The [[Call]] semantics for built-in functions have no corresponding return->normal unwrapping.
(The current spec text ends up propagating a return completion to the caller - that is, as currently written, it would cause a return from the code which called fromAsync.)
The current spec misuses
~return~completions. Those are use for propagating a literal syntacticreturnin an ES function up through any intermediate syntax (which is handled by the?macro) to the[[Call]]AO which invoked the function, where it is unwrapped into a normal completion (in step 10.2.1 of that algorithm).Built-in functions do not need to deal with that propagation, so they can (and do) just return a normal completion holding the value in question directly. The
[[Call]]semantics for built-in functions have no corresponding return->normal unwrapping.(The current spec text ends up propagating a return completion to the caller - that is, as currently written, it would cause a
returnfrom the code which calledfromAsync.)