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

Bind on WebAssembly.Function #46

Open
SPY opened this issue Oct 19, 2023 · 2 comments
Open

Bind on WebAssembly.Function #46

SPY opened this issue Oct 19, 2023 · 2 comments

Comments

@SPY
Copy link
Collaborator

SPY commented Oct 19, 2023

TLDR: bind should be overrided for WebAssembly.Function to return regular JS Function.

According to the proposal WebAssembly.Function is a subclass of regular JS Function and Function.prototype in its prototype chain. It makes possible to call Function.prototype.bind on WebAssembly.Function object. It returns Bound Function exotic object with its [[Prototype]] internal field set to a prototype of target - WebAssembly.Function.prototype in our case. After that we get an object indistinguishable from WebAssembly.Function using instanceof machinery, but it couldn't be used as an argument for Table.set.

let wafn = new WebAssembly.Function({parameters: ['i32'], results:[]}, _ => 0)
let pseudo_wafn = wafn.bind(null)
console.log(pseudo_wafn instanceof WebAssembly.Function) // true in current state of things
console.log(pseudo_wafn.type().parameters) // ['i32']? []? but Function.prototype.bind knows nothing about WebAssembly.Function
let table = new WebAssembly.Table({ initial: 1, element: "anyfunc" })
table.set(0, pseudo_wafn) // throws an exception. pseudo_wafn is not a real WebAssembly.Function

To keep it consistent and predictable I propose to override bind on the level of WebAssembly.Function.prototype to behave exactly like original one, but return BoundFunctionObject with a regular function prototype. It allows to keep ergonomic on JS side without changing ecma262 spec.

@eqrion
Copy link
Contributor

eqrion commented Dec 17, 2023

I think this makes sense. Do you know if there is any precedence for this with other function objects that derive from Function.bind?

@SPY
Copy link
Collaborator Author

SPY commented Dec 18, 2023

No, I'm not familiar with such precedence. Other function objects(AsyncFunction, AsyncGeneratorFunction) behave the same way as their BoundFunctionObject in any applications. So there is no such problem with them.

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

No branches or pull requests

2 participants