Skip to content
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

CreateBuiltinFunction’s signature has changed #1106

Open
bathos opened this issue Feb 22, 2022 · 6 comments · May be fixed by #914
Open

CreateBuiltinFunction’s signature has changed #1106

bathos opened this issue Feb 22, 2022 · 6 comments · May be fixed by #914

Comments

@bathos
Copy link
Contributor

bathos commented Feb 22, 2022

ECMA-262 changed the signature of the CreateBuiltinFunction abstract op last year. Perhaps there were changes on both sides around the same time or something, though, since the PR says it “preserves compatibility for WebIDL,” but it seems all 30 usages in Web IDL are incorrect now.

PREVIOUS SIGNATURE: ( steps, internalSlotsList [ , realm [ , prototype ] ] )
CURRENT SIGNATURE:  ( behaviour, length, name, additionalInternalSlotsList [ , realm [ , prototype [ , prefix ] ] ] )

Web IDL usages all look like one of these:

CreateBuiltinFunction(steps, « [[Unforgeables]] », realm, constructorProto).
CreateBuiltinFunction(steps, « », realm)
CreateBuiltinFunction(steps, « »)

Explicit names and lengths are required. In cases where Web IDL is already setting them afterwards, it’d just become a single call:

// ...where it’s currently like this:
Let F be ! CreateBuiltinFunction(steps, « », realm).
Perform ! SetFunctionName(F, id).
Perform ! SetFunctionLength(F, 0).

// ...it should be like this:
Let F be ! CreateBuiltinFunction(steps, 0, id, « », realm).

Web IDL doesn’t always set a name or length, though. I’m not certain what’s right for those cases, but it looks like they’re all Promise-related and mirror patterns in ECMA-262. Since the ES versions already use the new signature, it’s likely their values (e.g. empty string for name) are what’s wanted here, too.

(Possibly of interest to @ExE-Boss, the boss of ExEs.)

@bathos
Copy link
Contributor Author

bathos commented Feb 22, 2022

Oh, I’d only searched issues earlier and missed that there’s an open PR meant to address this (which is from the same time, explaining the comment). I suppose it makes sense to leave the issue open though as it’s still pending.

@domenic
Copy link
Member

domenic commented Feb 22, 2022

Yes, unfortunately that PR is blocked on whatwg/sg#93. A replacement PR would be very welcome.

@bathos
Copy link
Contributor Author

bathos commented Feb 22, 2022

Oof. Funny enough, that means I also can’t contribute PRs to Web IDL now. I’ve had my name since I was a child, but it isn’t the name printed on my birth certificate. Unfortunate that this policy disproportionately prevents people belonging to specific demographic groups from participating.

@domenic
Copy link
Member

domenic commented Feb 22, 2022

As long as you are willing to enter the name you sign legal contracts with, into a form on the internet, you are able to fill out the participant agreement.

@bathos
Copy link
Contributor Author

bathos commented Feb 22, 2022

Would that name appear in the public https://github.com/whatwg/participant-data/blob/main/individuals.json? It seemed like you had a good solution in that thread (a distinct participant-data-private), but it wasn’t clear to me that it had been adopted.

@domenic
Copy link
Member

domenic commented Feb 22, 2022

Yes, it would appear publicly. If that's not acceptable then indeed you too are stuck :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants