Editorial: Stop saying that a built-in function can be implemented as an ECMAScript function

[jmdyck]

(... and other tweaks to 10.3 "Built-in Function Objects")

This covers much the same ground as #3007, but takes a different enough approach that I figured it should be a separate PR.

• Commit 1 eliminates anything that says a built-in function can be implemented as an ECMAScript function. (This doesn't eliminate the possibility that it can be implemented that way, just leaves it unsaid.)

• Commit 2 deletes prose that just repeats step 10 of built-in [[Call]] and [[Construct]]. (As suggested by Editorial: Re-word re built-in function implemented as ECMAScript function #3007 (comment))

• Commit 3 moves a single-sentence paragraph about the "prototype" property of built-in functions from 10.3 "Built-in Function Objects" to 18 "ECMAScript Standard Built-in Objects". (Other than that sentence, 10.3 doesn't say anything about properties, whereas 18 says lots about properties, so 18 seems like a more appropriate location.) This starts to get into some of the territory covered by PR Editorial: Remove function-specific text from object-specific section #539. (In particular, I made the same suggestion at the bottom of Editorial: Remove function-specific text from object-specific section #539 (comment).)

• Commit 4 then re-works everything left in 10.3 "Built-in Function Objects". The organization is roughly the same (talk about internal slots, then talk about internal methods), but I think the flow is better. Also:

  • It states explicitly that a built-in function is an ordinary object, which is only implicit in the definition of ordinary object.
  • It avoids using "behaviour" in two different ways.
  • It avoids naming the slots that a built-in function "inherits" (since that can go out-of-date, and already has).
  • It's more specific about which built-in functions support [[Construct]].
  • It replaces the phrase "function body behaviour" (which is odd for a built-in) with a more specific tie-in to the [[Call]] and [[Construct]] algorithms.

[michaelficarra]

Can we <dfn> "built-in function" here?

[jmdyck]

Well, if we were going to <dfn> "built-in function", this would be the section to do it. (Not with that sentence though, as it isn't a definition.) Is there an editorial policy on <dfn>ing terms that already have a definition in Terms & Definitions?

(If there are editorial thoughts on disbanding "Terms & Definitions", please see Issue #1278.)

[michaelficarra]

Ah, I had forgotten about #1278. I just put a similar suggestion in #3146.

Alternatively, for anything with its own actual <dfn>, I would prefer we don't have a T&D section. But we can follow up with that later.

[michaelficarra]

Suggested change

	<p>In addition to the internal slots required of every ordinary object, a built-in function object must also have the following internal slots:</p>
	<p>In addition to <a href="#sec-ordinary-object-internal-methods-and-internal-slots">the internal slots required of every ordinary object</a>, a built-in function object must also have the following internal slots:</p>

Suggested change

	<p>In addition to the internal slots required of every ordinary object, a built-in function object must also have the following internal slots:</p>
	<p>In addition to the internal slots required of every ordinary object (see <emu-xref href="#sec-ordinary-object-internal-methods-and-internal-slots"></emu-xref>), a built-in function object must also have the following internal slots:</p>

Maybe something like this to allow the reader to easily navigate there?

[jmdyck]

Seems a bit overkill, given that the preceding sentence ended with a link to the same section. But done.

[michaelficarra]

I feel like this paragraph could maybe be better accomplished via a note or clarification near that step of BuiltinCallOrConstruct.

[jmdyck]

I've recast it as a NOTE-step in BuiltinCallOrConstruct. It's almost a tautology, but I think it might be helpful.

Looking it over, I think I lost something from the status quo's "behaviour for both [[Call]] and [[Construct]] invocations", so I've added another sentence to 18 "ECMAScript Standard Built-in Objects".

[michaelficarra]

LGTM otherwise.