Editorial: Define required internal slots in CreateBuiltinFunction steps

[ExE-Boss]

The way CreateBuiltinFunction is currently specified would’ve resulted in it not having the [[Prototype]], [[Extensible]], [[Realm]] and [[ScriptOrModule]] internal slots unless they were explicitly passed using CreateBuiltinFunction(steps, « [[Prototype]], [[Extensible]], [[Realm]], [[ScriptOrModule]] »).

I’ve also made it optional in preparation for converting many of the built‑in functions to use abstract closures after #2109.

See also:

• Editorial: Add support for Abstract Closures to CreateBuiltinFunction #2109
• Normative: Set function name and length in CreateBuiltinFunction #2116

---

Preview (#sec-createbuiltinfunction)

[anba]

Built-in functions can be implemented as ECMAScript function objects, in which case they have even more internal slots. If they are not implemented as ECMAScript function objects, but instead as implementation provided function exotic objects, they are already described as required to have these slots:

If a built-in function object is implemented as an exotic object it must have the ordinary object behaviour specified in 9.1. All such function exotic objects also have [[Prototype]], [[Extensible]], [[Realm]], and [[ScriptOrModule]] internal slots.

[ExE-Boss]

they are already described as required to have these slots:

This makes that requirement explicit, rather than implicit.

[anba]

But it gives the impression that only [[Prototype]], [[Extensible]], [[Realm]], and [[ScriptOrModule]] are needed, which isn't true for ECMAScript function objects. If this needs to be explicit, it should have two branches to cover the case if the built-in function is an ECMAScript function object or an exotic object. And in each branch the appropriate slots should be initialised. (For example right now the spec also doesn't cover how the other internal slots for a built-in function which is an ECMAScript function object are initialised. This is all left to be defined in an actual implementation.)

[ljharb]

The requirement is already explicit - it's just not in this location.

[ljharb]

This also seems unnecessary - func is "a new built-in function object", so it automatically has these slots with no further spec text.

[ExE-Boss]

I’d like to convert CreateBuiltinFunction to use MakeBasicObject if possible.

[bakkot]

I am against this change. Switching on implementation details in normative prose seems bad to me.

[jmdyck]

In the current spec, I think the only obvious example of switching on an implementation detail is:

• If an implementation-defined debugging facility is available and enabled, ....

For "host", there's:

• If the host requires use of an exotic object to serve as realm's global object, ...
• If the host requires that the *this* binding in realm's global scope return an object other than the global object, ...
• If <various conditions> and ! HostHasSourceTextAvailable(_func_) is *true*, ...

That's all I could find.

[jmdyck]

@bakkot:

Switching on implementation details in normative prose seems bad to me.

9.3 Built-in Function Objects says that if you implement a built-in function as an exotic function, then it must satisfy some extra requirements (that run-of-the-mill exotic functions don't have to). So that is normative prose that is switching on an implementation 'detail'. The proposed text that you were objecting to seems comparable, just in algorithmic form.

[jmdyck]

As @anba pointed out: if _func_ is an ECMAScript (i.e. ordinary) function object, it must have all the internal slots listed here, but this operation doesn't mention most of them or say how they're initialized. Of course, that's been true since CreateBuiltinFunction was introduced, but this PR appears to be trying for completeness. I think it's somewhat misleading in its current state.

[ExE-Boss]

I’m not sure how I should specify that given @bakkot’s review in #2115 (comment).

[jmdyck]

If @bakkot continues to object, then I think the solution is for CreateBuiltinFunction to not be as specific about slots as you'd like. E.g., you could ditch the construction of _internalSlotsList_ and then say something like: The new function object has the internal slots required by either (9.2) or (9.3), as appropriate, and also has internal slots whose names are the elements of _additionalInternalSlotsList_.

(It should be possible to replace "either (9.2) or (9.3), as appropriate" with just "(9.3)", since 9.3 deals with all built-in functions, and covers the ordinary/exotic implementation choice. But I think, as 9.3 currently stands, that would be a little misleading, as readers would only look at the slots explicitly mentioned in 9.3 and not consider those included by reference to 9.2.)

[jmdyck]

I've been requested to review this, and I'm willing to do so, but I think the merge conflicts should be resolved first. In particular, note that #2190 dropped the [[ScriptOrModule]] slot for exotic built-ins.

[ljharb]

@jmdyck i've rebased it; feel free to take a look.

[jmdyck]

It turned out my comments wouldn't have fit very well into the "suggested change" boxes, so instead I filed ExE-Boss#1 against this PR's branch.

[jmdyck]

It's still the case (as it has been since CreateBuiltinFunction was introduced) that if the function being created is an ordinary function object, CreateBuiltinFunction doesn't say how most of its internal slots are initialized. Without trying to 'fix' that shortcoming, we could maybe at least acknowledge it in a Note. E.g.:

NOTE: If func is an ECMAScript function object, it has many other internal slots that must be initialized, but this operation does not address how that happens.

With or without that, I think this PR is somewhat clearer than the status quo about internal slots of built-ins.

[michaelficarra]

This looks good, but it will need to be rebased (due to #545) to have the proper header format for CreateBuiltinFunction.

[bakkot]

Done.

changes addressed

changes addressed