You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not possible for JS callees to gain access to S.mems[0] without it being explicitly exported under a prenegotiated name. This means that it's not possible to work with functions that require memory access within the wasm start function, and it makes it impossible to import a function with the esm proposal that can access the memory.
This seems like a super important step to consider with the design of memory moving forward. I've seen it be a design blocker at least once within WASI (WebAssembly/WASI#19), and I've had to work around it in various other projects I've worked on.
The main idea so far seems to be first-class references to memories.
It's not possible for JS callees to gain access to S.mems[0] without it being explicitly exported under a prenegotiated name. This means that it's not possible to work with functions that require memory access within the wasm start function, and it makes it impossible to import a function with the esm proposal that can access the memory.
This seems like a super important step to consider with the design of memory moving forward. I've seen it be a design blocker at least once within WASI (WebAssembly/WASI#19), and I've had to work around it in various other projects I've worked on.
The main idea so far seems to be first-class references to memories.
cc @linclark @tschneidereit @lukewagner
The text was updated successfully, but these errors were encountered: