A proper solution for this problem will also help with the WebGPU API. Mapping a GPU resource returns a JS array view, which currently requires a memcpy-roundtrip into and out of the WASM heap (for instance see here in Emscripten's WebGPU shim: https://github.com/emscripten-core/emscripten/blob/37aa752eb...).

Ideally the array view could either be mapped directly into the WASM heap, or at least would be accessible from the C/C++/Rust side with a special pointer type (maybe WASM should get a segmented address space like back in the 286 days lol).

There are stray references to the concept of multiple address spaces (or 'memories') in the wasm spec at present, and I recall at one point you may have always been passing 'memory #0' to your load/store opcodes before it was dropped from 1.0. It looks like people are still working on that as the solution.

https://github.com/WebAssembly/multi-memory

> Add a memory index to all memory-related instructions.

> Loads and stores have the memop field, in which we can allocate a bit indicating a memory index immediate in the binary format.

> All other memory instruction already have a memory index immediate (which currently has to be 0).

Which most likely will never happen, given the security constraints of browsers.

For once, this would not expose any additional attack surface other than the inevitable bugs in the C++ implementation of it that gets shipped in all the browsers.

It really wouldn't add any additional attack surface compared to accessing the same data through Javascript though.

This is the weird thing about the GC proposal: it's not really adding a GC to WASM, as it is more adding an opaque object reference system similar to Java or similar, independent from linear memory (the goal of Mark Miller was to run without any linear memories at all). C and C++ and their compilers are based on the concept of a linear, addressable memory and adding in opaqueness really is like pulling teeth.

I can't see much success for the GC proposal, tbh. It's really fighting a very strong current.

The goal of Wasm GC is to allow GC-using languages to be ported to wasm. They already can today, of course, but this will make them more efficient in some cases, with smaller downloads and faster execution. This might be a very big deal - most code written today is written in GC languages! - and that is separate from the story for C/C++/Rust/Zig and other linear-memory languages.

Concretely, the wasm community already has GC ports in progress for Java, Dart, and Kotlin, and there is a lot of promise shown there.

The GC proposal is going to get used by things like Java/C# compilers and runtimes, nobody writing C/C++ has a good reason to use it, unfortunately. Unless you really want the JS runtime's garbage collector up in your business. Cross-language collection for DOM objects, maybe?

It's still the recommended way to use DOM objects from C/C++, right? interface-types/host-bindings was stopped so I don't see any other solution than anyref-ing your way to hell (or JS wrappers). Are we going to bring hat pointers back?

Wait is interface types no longer happening or did I misunderstand your comment?