Editorial: support built-in async functions #2942
Conversation
| @@ -13866,7 +13866,7 @@ <h1>Built-in Function Objects</h1> | |||
| <p>The behaviour specified for each built-in function via algorithm steps or other means is the specification of the function body behaviour for both [[Call]] and [[Construct]] invocations of the function. However, [[Construct]] invocation is not supported by all built-in functions. For each built-in function, when invoked with [[Call]], the [[Call]] _thisArgument_ provides the *this* value, the [[Call]] _argumentsList_ provides the named parameters, and the NewTarget value is *undefined*. When invoked with [[Construct]], the *this* value is uninitialized, the [[Construct]] _argumentsList_ provides the named parameters, and the [[Construct]] _newTarget_ parameter provides the NewTarget value. If the built-in function is implemented as an ECMAScript function object then this specified behaviour must be implemented by the ECMAScript code that is the body of the function. Built-in functions that are ECMAScript function objects must be strict functions. If a built-in constructor has any [[Call]] behaviour other than throwing a *TypeError* exception, an ECMAScript implementation of the function must be done in a manner that does not cause the function's [[IsClassConstructor]] internal slot to have the value *true*.</p> | |||
| <p>Built-in function objects that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function. When a built-in constructor is called as part of a `new` expression the _argumentsList_ parameter of the invoked [[Construct]] internal method provides the values for the built-in constructor's named parameters.</p> | |||
| <p>Built-in functions that are not constructors do not have a *"prototype"* property unless otherwise specified in the description of a particular function.</p> | |||
| <p>If a built-in function object is not implemented as an ECMAScript function it must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions:</p> | |||
| <p>Unless otherwise specified, a built-in function object must provide [[Call]] and [[Construct]] internal methods that conform to the following definitions:</p> | |||
There was a problem hiding this comment.
This says that a built-in function is exotic (and synchronous) unless otherwise specified. So then a built-in would be ordinary (i.e., an ECMAScript function object) only if specified to be so. But, of course, none of them are, because the spec explicitly says that built-ins can be ordinary or exotic.
There was a problem hiding this comment.
@jmdyck I don't understand this comment. I think I'm missing some assumption. Can you rephrase?
There was a problem hiding this comment.
-
10.3 "Built-in Function Objects" says that built-in functions may be implemented as either ECMAScript function objects or as exotic function objects.
-
10.2 "ECMAScript Function Objects" says that an ECMAScript function object has the
[[Call]]internal method defined in 10.2.1. -
10.3 "Built-in Function Objects" says (in the status quo) that a built-in function that isn't implemented as an ECMAScript function object must have the
[[Call]]internal method defined in 10.3.1.
So, in the status quo, a built-in's [[Call]] can be either 10.2.1 or 10.3.1, and the spec leaves the choice to the implementation.
-
This PR replaces the third point with a sentence that says a built-in function object must use 10.3.1 "unless otherwise specified".
-
But for all of the existing built-in functions, the spec never specifies whether to use 10.3.1 or 10.2.1 (because it's leaving that choice to the implementation), so it is never "otherwise specified", so the "unless otherwise specified" clause never holds.
So this new sentence implies that all existing built-in functions must use 10.3.1.
There was a problem hiding this comment.
(And I know that, at some point, the idea was floated to get rid of the 10.2.1 possibility for built-ins, but that's clearly not what this PR is trying to accomplish. That would presumably be a separate PR.)
There was a problem hiding this comment.
This is not an observable difference. I am okay with it. Besides, we wanted to eliminate all the implications (and explicit statements) that "built-ins can be ECMAScript code, too" because it doesn't matter.
There was a problem hiding this comment.
Is there any example of built-in functions that are exotic?
In the spec? No, because the spec says that's up to the implementation.
If you're asking for an example of an implementation in which built-ins are exotic, there's v8. E.g. here is its implementation of String.p.endswith. It looks like most/all of its builtins are implemented in the Torque programming language. Not in ECMAScript, anyhow, so they're not 'ECMAScript function objects', i.e. not ordinary functions, so they're exotic functions.
In SpiderMonkey, it's implemented in C++, so also exotic.
My guess is that built-ins are exotic in most high-performance implementations, because they're easier to optimize that way.
There was a problem hiding this comment.
Resolution from editor call is to change the definition of ordinary object to explicitly allow these [[Call]] and [[Construct]] methods so they're all considered ordinary for now. We'll do this in a separate PR.
There was a problem hiding this comment.
Resolved in #2969.
There was a problem hiding this comment.
#2969 expands the definition of "ordinary function" to include all built-in functions (however implemented). But I don't think that resolves this, because my concern doesn't hinge on the definition of "ordinary function". If you look at my response to bakkot above, it all still holds in a post-2969 spec (except that "exotic" in the first point now becomes "non-ECMAScript").
(Yes, it was during discussion of this concern that the editors call decided to expand the definition of "ordinary", but maybe that was just to deal with the discovery that built-ins could be exotic?)
There was a problem hiding this comment.
I think PR #3007 would be a basis for resolving my concern.
| @@ -13938,7 +13938,10 @@ <h1> | |||
| 1. If _prototype_ is not present, set _prototype_ to _realm_.[[Intrinsics]].[[%Function.prototype%]]. | |||
| 1. Let _internalSlotsList_ be a List containing the names of all the internal slots that <emu-xref href="#sec-built-in-function-objects"></emu-xref> requires for the built-in function object that is about to be created. | |||
| 1. Append to _internalSlotsList_ the elements of _additionalInternalSlotsList_. | |||
| 1. Let _func_ be a new built-in function object that, when called, performs the action described by _behaviour_ using the provided arguments as the values of the corresponding parameters specified by _behaviour_. The new function object has internal slots whose names are the elements of _internalSlotsList_, and an [[InitialName]] internal slot. | |||
| 1. If _behaviour_ is described as async, then | |||
There was a problem hiding this comment.
What's the verbiage for describing an async AC? "Let c be a new async Abstract Closure"? Or "Async Abstract Closure" with capital A?
There was a problem hiding this comment.
I would say "async Abstract Closure", I think; the idea is what we will say "async function" or "async method" for the built-in function case (as in proposal-iterator-helpers).
We don't actually have any async ACs at the moment so it's not established yet.
This comment was marked as resolved.
This comment was marked as resolved.
FIXME: The check in builtin.js for Object.getPrototypeOf(Array.fromAsync) === Function.prototype might be wrong, depending on tc39/ecma262#2942 (comment)
|
Per plenary, built-in async functions will continue to have Function.prototype as their prototype. |
|
Roughly speaking, the status quo says that a function is ordinary if its [[Call]] conforms to either 10.2.1 or 10.3.1. This PR defines a distinct [[Call]] for built-in async function objects, which implies that these objects are not ordinary. Is that intentional, or do you need to tweak the definition of ordinary to include them? |
|
Recording my thoughts here for the record. While being able to specify built-ins as async functions in spec text significantly aids spec authors and many readers, I've found that it simultaneously really hinders understanding by implementers that work in a non-self hosting implementation, like V8. For non-self hosting implementations, the implementer would need to do a manual transform to some kind of state machine. This manual transformation process increases the likelihood of bugs and subtle non-interop (like getting the number of Promise ticks wrong or something). There are possible paths forward. The long-term solution is for V8 to be build something so that async functions can be written as straightline code as well. The spec can also include the transformed version and offer an alternate formulation of async builtins. |
This adds support for built-in async functions, as needed by the async iterator helpers and
Array.fromAsyncproposals.