-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: Set function name
and length
in CreateBuiltinFunction
#2116
Normative: Set function name
and length
in CreateBuiltinFunction
#2116
Conversation
name
and length
paremeters to CreateBuiltinFunction
name
and length
paremeters to CreateBuiltinFunction
[WIP]
I'm confused; the steps themselves should already specify the name and length. Why are they needed here? |
They do not. |
For example, https://tc39.es/ecma262/#await-fulfilled says "The "length" property of an Await fulfilled function is 1.", and since it says they're anonymous, that means the name is the empty string. Any "steps" that don't specify these should be fixed to do so. |
There is prose which specifies these, yes, but not steps. It is odd to explicitly create an object and have steps to set up some of its properties, but have others be described only in prose, which is the current state of affairs. (The concrete reason to add these as parameters is so that they can be used when passing an abstract closure instead of a sequence of steps, in which case there is no obvious place to put normative prose.) |
The length and name of a function defined from steps should imo be determined at the steps' location, and not where the steps happen to be used. |
I am fine with mentioning it in those locations, but it seems pretty odd to say that's where it should be determined, given that the place the steps are used is the place that sets up internal slots, etc. (Also, I would like to eventually inline most such steps into the callsites of CreateBuiltInFunction, as in #2109, and this is effectively a prerequisite for that, since after such an inlining there is no longer any other place to put the name and length.) |
To me, the steps are what defines the function. Just like how methods define the steps, name, and length in one place, I think these ideally should too. In other words, I'd prefer to see all these things moved to the steps definition location, rather than moving more of them out to the callsite. |
ce0c88c
to
7272289
Compare
name
and length
paremeters to CreateBuiltinFunction
[WIP]name
and length
in CreateBuiltinFunction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per today's editor call, let's make the following change to CreateBuiltinFunction's signature, as well as every callsite of it.
For steps-based functions, they should include (at the CreateBuiltinFunction callsite) steps like the following:
1. Let _length_ be the number of non-optional parameters of _steps_.
1. Let _name_ be the empty String.
Also, in https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects, let's change
Each built-in function defined in this specification is created by calling the CreateBuiltinFunction abstract operation (9.3.3).
to be
Each built-in function defined in this specification is created by calling the CreateBuiltinFunction abstract operation (9.3.3). The values of the _name_ and _length_ parameters are the initial values of the _length_ and _name_ properties as discussed below.
Arguably, the length parameter should be optional, as it can be determined inside CreateBuiltinFunction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for asking for more changes. Reading this again, the language of "Let length be the number of non-optional parameters of steps" is too strange IMO.
If the constraint that @ljharb wants to keep is that the length values be co-located with the steps, I think I'd prefer "Let length be the number of non-optional parameters of a XYZ function as specified below/in XYZ Functions." Basically mirroring the language of "Let steps be the steps of ..."
Note to self: figure out if latitude is needed for the web reality of builtin getters and setters and the presence of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation reality doesn't need extra latitude for accessors, so by my reading this PR is good to go.
@ExE-Boss This needs a rebase again, after which I believe it will be ready to land. Do you want to take care of it? Otherwise the editors will get to it in a week or two. |
bce3f06
to
677e20d
Compare
tc39#2116) Co-authored-by: Kevin Gibbons <bakkot@gmail.com> Co-authored-by: Shu-yu Guo <syg@chromium.org>
677e20d
to
3dd0b48
Compare
This PR is normative as it defines the order in which the
length
andname
properties are added to built-in functions.I’ve added
name
as a parameter, since abstract closures don’t have names, which would make using them to create non‑anonymous functions impossible.It also preserves compatibility for WebIDL, which uses inline definitions for steps.
Tests: tc39/test262#2921
Unsolved issues:
prefix
parameter toSetFunctionName
(Normative: Set functionname
andlength
inCreateBuiltinFunction
#2116 (comment))Blocks:
CreateBuiltinFunction
#2109See also:
CreateBuiltinFunction
steps #2115Preview (#sec-createbuiltinfunction)