Lets say hypothetically Kotlin WASM gains the ability to port a Kotlin Native library (incl ones that provide a Kotlin binding to a C library) over to the platform. How would the porting process work? This hypothetical situation came about out of what was done with Rust and the LVGL ( https://lvgl.io/ ) library to port it to WASM ( https://forum.lvgl.io/t/rust-bindings-for-littlevgl/2386/12 ).

Hypothetically: 1. Port libraries that provide C api to be compliable to Wasm, unless they are already ported. This would depend on the library language C, C++, Rust, etc. and its dependencies. 2. Replace K/N specifics with common code and expect-actuals. It would hypothetically make sense for K/Wasm to have a C interop similar to K/N, but it may end up having some limitations and deviations.

From a hypothetical impression the K/N library would need to be mostly rewritten as a K/W library that taps into the common code as mentioned, and uses the WASM version of the C library. Seems as though it would heavily rely on the C library maintainer providing a ready made WASM version. Would involve too much work otherwise.

Sounds good. The way I see it, wasm will have 3 major interop options to choose from: JS, C ABI and Interface Types. JS will be ready initially. C ABI and IT will come after.

Are the Interface Types tied into some sort of WASM library format? Is there a web standard for a WASM library format?

Core Wasm is low level. Languages defined their own library formats on top of Wasm, they define some sort of ABI, very similar to what they do when compiled to native code. Interface Types is one of such formats designed to describe high-level types like strings, records, arrays in a way that every language can produce and consume them.

I personally more like an idea to be able load API from any wasm file instead of having C interop.

Loading any Wasm file could be a useful feature on its own. But I don't think this would be a good replacement for C interop because pure Wasm file no longer has information about high-level C types. All pointers would look like an

Int

and you would have to manually specify field offsets in your structs.

I think many of us can agree that K/W interop with C libraries is important (especially with porting some K/N libraries over to K/W), but would be lower priority than interop with JS/TS libraries. Last time I looked at the size of the K/N ecosystem (with only the Linux targets) it was about the same size as the K/JS ecosystem. If about 30% of the K/N ecosystem was ported over to K/W then the K/W ecosystem would get a good boost. This is a good way to increase the attractiveness of K/W and helps set Kotlin apart from many other high level languages that either already support WASM, or are planning to do so in the near future.

Issue you linked seems to be about integrating LVGL interop Wasm3 natively without compiling it to Wasm. As far as I understand, the plan is to provide API via host imports, which looks fine. Do you have any specific questions?

Do Interface Types cover manual memory management?

Not directly. IT is not fond of sharing linear memory, and values are copied when passed between components. However, there will be handles to resources that could be freed. Memory allocation could be seen as such resources.

Would the manual memory management have shim type APIs (same signature, different behaviour) just like the ones for File system access with WASM?