liamappelbe
commented
1 year ago I'm tempted to add a mode to package:ffigen that can scan a C header and generate package:wasm bindings. But it's tricky because the encoding of higher level types like strings depends on your target (eg WASI or Emscripten).
It's probably safer to just look at the wasm module's type info and generate some low level bindings. The conversion to higher level types can happen in a wrapper.
modulovalue
It would be good to have some machinery that is able to generate bindings for any given WASM module i.e. generate type-safe APIs in Dart that would allow us to use the declarations declared in a WASM module without having to use any unsafe features (i.e. casting) ourselves. There are some open questions:
Would it be practical to extract the type information from a wasm binary itself? This would not give us the best type information, because the type system of WASM seems limited, but it would give us some safety, and that safety could be guaranteed to be sound.
Consider dart: I think, a dart program compiled to wasm would have to store strings in an array of code units. We could create zero cost views over those code units using native dart APIs. However, how can we soundly prove that any given list of e.g. uint16 is meant to represent a String? Would the dart2wasm compiler have to generate the bindings? Should it generate some intermediary file that allows us to generate more refined bindings? Will dart2wasm store this information in the compiled WASM module itself? We should perhaps look into how other languages are tackling the generate-type-safe-bindings issue.