Passing a WasmExportedFunction to new WebAssembly.Function

[gahaas]

What should happen when a WasmExportedFunction is passed as the callable to new WebAssembly.Function? I was not able to find this case in the proposal.

My guess would be that a signature check should happen: if the signature of the WasmExportedFunction matches the signature passed to new WebAssembly.Function, then the WasmExportedFunction is returned. If the signature does not match, then a TypeError is thrown.

[lukewagner]

That would certainly be symmetric to how re-exports of function imports work (which is the hack WebAssembly.Function is replacing), and thus we could rationalize the instantiation logic in terms of WebAssembly.Function, which I think is a nice thing.

Moreover, engines currently enjoy a 1:1 relationship between core wasm funcaddr and WasmExportedFunction objects, which allows an engine to easily move back and forth between the two. One concrete place this comes up is in WebAssembly.Table.prototype.set: we want to store a raw code pointer in the table, forgetting the originating JS function object, knowing that we can recover it on-demand later if needed for WebAssembly.Table.prototype.get. If we lost the 1:1 correspondence, we'd have to separately remember which JSFunction was stored into the table. So that's another reason to like your suggestion.

The obvious downside is the weirdness of new not always creating a new JS object. Now, this is already technically possible to do via JS constructors:

var obj = {};
function ctor() { return obj; }
console.log(new ctor() === new ctor());  // true

but maybe that's a weird thing for a builtin constructor to specify? I dunno; @ajklein ?

If we consider this a problem, we could maybe say that WebAssembly.Function wasn't a constructor, only a builtin function that had the same coercive behavior of "create a new WasmExportedFunction if the input is not one already" as, e.g., Object:

var obj = {};
console.log(obj === Object(obj));  // true
console.log(10 !== Object(10)); // true

[ajklein]

Return override is definitely a strange feature of JS, and causes unnecessary allocations.

What's the use-case for doing special handling here? It doesn't seem like someone would do this on purpose, since if they knew they already had a WasmExportedFunction they wouldn't even try to wrap it with new WebAssembly.Function.

[lukewagner]

Good point; I don't know if there is a real use case and so a third option is to just throw when given an already-wasm function. If the caller doesn't know statically (maybe it's on some common path for setting a table element), they would need to write:

if (!(f instanceof WebAssembly.Function))
  f = new WebAssembly.Function(f, sig)

which seems fine. This would certainly be simpler.

[gahaas]

@lukewagner I'm not convinced of throwing when given an already-wasm function. It is true that caller could simply check if a function f is already an instance of WebAssembly.Function, but in reality I would expect that such a check would often be missing, and that it would lead to exceptions that are misleading for the web developer.
Additionally, throwing would make the behavior different than the behavior of importing and re-exporting a function in a WebAssembly instance.
In that sense I like the idea you propose in #13 (comment), that we could make WebAssembly.Function not a constructor but a builtin function. I cannot think of a good name of that builtin though. WebAssembly.wrapFunction maybe?

[lukewagner]

@gahaas Fair enough; I don't have a strong opinion here, I'm just enumerating options. Since I think we need WebAssembly.Function to exist (whether or not it's a constructor), and since there is symmetry to how String and Object work as functions, I think it'd be fine to just use Function instead of introducing a new wrapFunction, but I wouldn't trust my stylistic judgment ;)

[rossberg]

Oh, I'm only discovering this issue now...

Given that WebAssembly.Function is supposed to be a subclass of Function, it would seem bogus to throw on it, because that breaks subclass substitutability.

The easiest and cleanest behaviour would be to do nothing special and just create another wrapper regardless (i.e., return a new WasmExportedFunction that is a copy of the argument).

But with this being JavaScript, returning the argument unchanged (return override) would also be a viable option. At least that matches the behaviour of the Object constructor when applied to an object:

let o = {};
o === new Object(o);  // true

[tsyesika]

The easiest and cleanest behaviour would be to do nothing special and just create another wrapper regardless (i.e., return a new WasmExportedFunction that is a copy of the argument).

So I'm a little unclear what should happen in situations when the type of the WebAssembly.Function passed in does not match the type that you're constructing it with? Does this throw an error? does it wrap it regardless?

[rossberg]

The easiest and cleanest behaviour would be to do nothing special and just create another wrapper regardless (i.e., return a new WasmExportedFunction that is a copy of the argument).

So I'm a little unclear what should happen in situations when the type of the WebAssembly.Function passed in does not match the type that you're constructing it with? Does this throw an error? does it wrap it regardless?

Ah, nothing special: the wrapper calls it as if it was a JS function. So when called from within Wasm, arguments would actually go through two layers of conversion: first the new wrapper converts from Wasm to JS relative to one set of types and then the old converts JS back to Wasm relative to the other. If types don't match, this may or may not cause a TypeError somewhere, depending on the details.

(In that sense, it was inaccurate to say the new wrapper is a "copy". It's actually a function with different behaviour.)

But your question is also relevant for the return override semantics: and for that, it's indeed unclear what to do. So that's probably a bad idea.

[RossTate]

I would echo @rossberg that substitutability is a valuable principle (and similarly echo @ajklein that a good API here would be designed to let the user view the function as a black box); however, consistency in the API is also valuable. The problems here stem from problems in WebAssembly.instantiate, specifically 3.4 of read the imports. That process already violates substitutability. So if substitutability is considered here to be a good principle to follow, it should be applied to WebAssembly.instantiate as well, keeping the API here and there consistent. You should be able to do this for everything but identity semantics in the manner @rossberg suggests above.

[eqrion]

Coming back to this issue after a while. It sounds like there's motivation for WebAssembly.Function to be extensible in the future with options that allow you to customize how the wrapped function is invoked (see js-promise-integration, or binding the first argument to this). Having these options would be incompatible with having the constructor return the passed function when it's a wasm exported function.

It seems like the best semantics here are that the constructor takes any JS callable (which includes wasm exported functions) and unconditionally generates a wasm exported function that will invoke the callable using the provided function type (plus possibly some JS binding options in the future).

however, consistency in the API is also valuable. The problems here stem from problems in WebAssembly.instantiate, specifically 3.4 of read the imports. That process already violates substitutability.

The way I'd rationalize the linking behavior is that importing a function wants to take a WebAssembly.Function, but is lenient and will construct a WebAssembly.Function for you if you just provide a callable. That's different from the WebAssembly.Function constructor, which wants to take a callable, which by subtyping could be an exported function.

This linking process is similar for immutable globals, which want a WebAssembly.Global but are lenient and can construct a global for you if you just provide the value.

[SPY]

I agree with approach suggested by @eqrion
It also keeps new WebAssembly.Function algorithm brief and consistent with Exported Function creation procedure.
I added a spec wording for that in #42
I hope it resolves the issue.

[SPY]

Resolved offline on 2023 Wasm F2F Summit.