Andreas Rossberg

> For example why does wasm_module_imports return an owned vector but wasm_functype_params returns a vector owned by the original type? Generally, the driving factors for returning ownership were whether the...

They correspond to the "extern values" in the spec. In particular, that's what module instances take as lists for imports and exports. So you need a common type. The examples...

This seems to be a bug with Wasmtime's implementation of the C API, not the C API definition itself (this repo). Can you please file it against Wasmtime?

> Seems risky to rely on caller-only for ensuring that imports match. Well, that's how C works just about everywhere. There is no safety in C. But fair point about...

Hm, interesting, but the way I read it is that the restrictions stated there constrain implementations of POSIX and what implementation-specific symbols they can *add to POSIX header files*. AFAICS...

Sigh, modularity and name spacing are such a sad story in C. The only unqualified type names we define are the byte_t, float32_t, and float64_t synonyms. I agree that we...

Actually, the main benefit of the convention from my perspective is that you don't get into syntactic issues where you want to name a variable or function after a type,...

Well, this a proposal in fairly early stages, so I'm afraid there is no tooling or documentation yet.

In principle this makes sense to me (especially since it avoids source names). OTOH, I can imagine engines that would not want to maintain this information (esp. the byte offset)....

Done in #121, but I'm on the fence whether it's worth the extra verbosity in this case. If only C++ didn't conflate stricter enum typing with questions of scoping...