Statically customizing wasm exported function behavior

[eqrion]

In the meeting today there was discussion around how to avoid the overhead of wrapping a wasm function so that it takes a receiver argument.

This seems related to the problem of setting the prototype on wasm structs. We want to create/define something in wasm and customize the default reflection in JS somehow.

I wonder if the compile-time type import idea in this comment could be extended to let us specify the receiver for a wasm function.

We would provide a builtin type for the thisType which is a sub of externref. When defining a function, the param that uses this type would be populated from the this value. If there is no thisType, then the default applies. We could handle multiple this params by just choosing the first, falling back to no this, or splatting the this value to multiple params.

(type $thisType
  (import "wasm:js-function" "thisType")
  (sub externref)
)
(func (param (ref $thisType)) (param ...)
   ...
)

One downside to this approach is that the thisType would be typed externref and users would need to cast it themselves. This isn't going to be any slower, as engines have to do the cast no matter what. But it would cost binary size. We could possibly make the thisType import polymorphic so you can define whatever sub bound you want to workaround this.

cc @tlively @jakobkummerow @lukewagner

[tlively]

In general I don't think we should try to reuse type imports for semantically meaningful annotations that aren't actually related to types. You alluded to one issue with it, which is that thisType would be able to be used in all sorts of nonsensical places. Another issue is that it's not clear how you could compose the annotation type import with a real type import or another annotation type import, since imported types should probably only have a single bound.

If we're looking for a way to reuse a core Wasm mechanism to configure the JS-side behavior of a function, we could look into doing the same thing we're doing for structs and let the Wasm functions have custom descriptors. The configuration info could be installed on the function descriptors the same way we're installing JS prototypes on struct descriptors.

[eqrion]

In general I don't think we should try to reuse type imports for semantically meaningful annotations that aren't actually related to types

I think using the type system to try to express semantics is one of the things type systems are intended for. I'm not sure what you mean that this isn't related to types.

I do think it's fair that the using a type-import on a function argument is not precisely what you'd want, but that's an artifact of the wasm type system being pretty inexpressive for this sort of thing. As in the comment here for structs, it'd be more natural to have a function type extend a base function type that provides the first argument as a receiver. But that'd require even more type system changes to express this than just type imports.