Skip to content

Review implementability of WebAssembly.Function #16

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

Open
Ms2ger opened this issue Apr 15, 2020 · 11 comments
Open

Review implementability of WebAssembly.Function #16

Ms2ger opened this issue Apr 15, 2020 · 11 comments

Comments

@Ms2ger
Copy link
Contributor

Ms2ger commented Apr 15, 2020

The snippet

interface Function : global.Function {
  static FunctionType type(Function func);
};

is not valid WebIDL, and I don't see a clear way to make it so.

Note that it's already possible (though a little tedious) to create a host function from a JS function:

function host_function(f, { parameters, results }) {
  const builder = new WasmModuleBuilder();
  const functionIndex = builder.addImport("module", "imported", { params: parameters, results });
  builder.addExport("exportedFunction", functionIndex);
  const buffer = builder.toBuffer();

  const module = new WebAssembly.Module(buffer);
  const instance = new WebAssembly.Instance(module, {
    "module": {
      "imported": f,
    }
  });

  return instance.exports.exportedFunction;
}

We could easily introduce this coercion in Table#set() as well, without necessarily introducing this new type.

@backes
Copy link
Member

backes commented Jun 30, 2020

Thanks for bringing this up. The main motivation for adding the WebAssembly.Function constructor is to avoid the overhead of creating a module and an instance just for wrapping a host function for adding it to a WebAssembly.Table. Using this constructor is significantly faster at least in v8.

I am not sure what the original intention of inheriting from global.Function was. Maybe we can just drop that?

@rossberg
Copy link
Member

Well, it has the prototype and properties of a regular function, i.e., is a subclass. If WebIDL has no way to describe that then we have to invent our own. :)

@rossberg
Copy link
Member

@Ms2ger, we cannot build the conversion into Table#set, because it doesn't know the intended function type.

@backes
Copy link
Member

backes commented Jun 30, 2020

Well, it has the prototype and properties of a regular function, i.e., is a subclass. If WebIDL has no way to describe that then we have to invent our own. :)

What is the intended effect then? Do we want typeof (new WebAssembly.Function([...])) to return "function"? I am not sure JS folks would sign off on that...

@tschneidereit
Copy link
Member

What is the intended effect then? Do we want typeof (new WebAssembly.Function([...])) to return "function"?

I'd expect the answer to that to be "yes".

I am not sure JS folks would sign off on that...

Can you say more about why that would be the case? These are functions, and can be used in all the places functions can be used. Function can (in somewhat annoying ways, but still) be subclassed in JS right now, and instances of these subclasses have exactly this typeof behavior. See the code snippet in this SO question.

@rossberg
Copy link
Member

rossberg commented Jul 1, 2020

What is the intended effect then? Do we want typeof (new WebAssembly.Function([...])) to return "function"?

Absolutely yes. In addition to what @tschneidereit said, that is what you get today for a Wasm exported function. Clearly that shouldn't change all of a sudden.

@backes
Copy link
Member

backes commented Jul 1, 2020

Ah, I didn't know that it's possible in JS to subclass Function. In that case I agree that this is what we want. Weird that this is not expressible in WebIDL.

@backes
Copy link
Member

backes commented Jul 1, 2020

@Ms2ger can you clarify what exactly the problem with the original snippet is? Is it that global.Function does not exist in WebIDL?

@Ms2ger
Copy link
Contributor Author

Ms2ger commented Jul 1, 2020

That's certainly the first issue, yes.

@ajklein
Copy link

ajklein commented Oct 11, 2023

See whatwg/webidl#937 for the existing issue against WebIDL asking how to specify this.

@SPY
Copy link
Collaborator

SPY commented Oct 16, 2023

As I understand TC39 JSFunction interface could be reference in the same fashion as ArrayBuffer interface introduced in the spec. I overlooked this approach initially, but it looks right to me now.
Implemented it in #45.

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

6 participants