JS methods: pass receiver as param

[jakobkummerow]

The Overview currently states that the declarative custom section will cause wrapper functions to be generated for installed methods:

function methodname() { return exports[exportname](this, ...arguments); }

That's functionally fine and certainly works as an "as if" description. It would be more efficient, however, if we didn't need these functions to actually exist. Their only purpose is to pass through the JS-side "receiver" (i.e. the foo in foo.bar()) as the first parameter to the Wasm function (e.g. (func (export "bar") (param $foo-value (ref $foo)) ...)).
This functionality could be had more efficiently if exported Wasm functions themselves could request this behavior, as opposed to always ignoring the "receiver" as they do today. There's some design space how exactly this could be done:

(1) It could be an option in the Wasm signature definition. I'd be fine with that, but I also see that it doesn't really belong there, as it's an embedder-related concept that has no meaning for core Wasm.
(2) It could be a "stamp" applied by the Wasm/JS API. Roughly: WebAssembly.MarkAsReceiverIsFirstParameter(my_exported_func). The act of setting this option potentially has a cost, that's why I'd suggest it to be a one-way street (once a function is configured this way, it'll remain that way; no flip-flopping back and forth). I'd also expect manual usage of this API to be rare, but it's probably nice to have on general principle; and this proposal could then say that Wasm functions installed as methods receive the same treatment automatically.
(3) ...other ideas?

I currently don't see a way for engines to just do this silently under the hood: it's an observable difference in behavior. With the fully-declarative approach (#22) it might be feasible (essentially by allocating a different kind of exported function upon method installation); with the exports-based approach that's currently in the Overview I don't think it's possible to do this as an engine-internal optimization. Besides, I think it might be an efficiency improvement that'd generally be nice to have available even independent from the other features in this proposal.

[tlively]

And to be clear, having an API or other dedicated mechanism for this would be more efficient than the wrapper functions currently proposed because the engine would not be able to actually optimize out the wrapper functions, right? The wrappers would be observable in stack traces and with func.toString().

[jakobkummerow]

Right, the wrappers are observable in existence, identity, and behavior. For example, user code could verify that the wrapper and the export it wraps both exist, have different identities, and have different behavior.