Andreas Rossberg

@PiotrSikora, yes, but all such template magic has two problems: (1) it most likely breaks the goal of link-time compatibility between different implementations, and (2) it does not extend to...

Adding a 128 bit field to wasm_val_t will double the size of all parameter vectors etc., so it's kind of undesirable -- and not a sustainable direction if the plan...

Something like that, plus suitable ownership management (which is where it gets nasty).

@AndrewScheidecker, we don't know of any way to provide a generic and portably implementable call interface for functions in the absence of val_t. Also, automatic ownership management of reference values...

Ah, note that a wasm_module_t represents an already decoded module, which isn't necessarily expected to keep a reference to the binary it originated from. So the API will need to...

it currently returns null in that case, but that's not distinguishable from a null reference. So I agree this should probably be changed somehow.

Thinking about this some more I believe the current interface is fine. Bounds checks are a safety mechanism, not something that is intended to be used programmatically. In C land,...

Yeah, I understand the suggestion, but I'm sorry to say that my prior exposure has elicited an allergy to clang-format. Symptoms are cringing pain and curling toe nails when exposed...

Yes, this API is somewhat dangerous. The pointer is not valid when reused across arbitrary Wasm execution (or API calls to grow) -- if there was documentation, it should say...

This was a conscious decision, since many potential clients still have to operate or build in environments where C++14 availability is the best you can hope for and C++11 is...