Statically customizing wasm exported function behavior

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

Start with the proposed thisType import in this issue and the linked custom-descriptors comment; no implementation files or tests are named. Done would be an agreed receiver-semantics and type-system proposal, followed by identified implementation and validation work.