Jacob Gravelle

Not having followed the subtyping story too closely, I don't have much of a dog in this race. With that in mind, I would like to highlight how hostile the...

> hopefully I managed to address the hostility while still presenting the case. Thanks. I think that reads much clearer now actually, well done. > As we move forward with...

To clarify, I'm not saying we should loosen the web VM wording, or anything related to stage 4. Maybe we should, but we could independently have feature-specific requirements for earlier...

For what it's worth I have some support for _reading_ reloc and linking sections in a tool I'm working on to generate emscripten-readable metadata (currently called lld-metadata, which will change...

> With the recipe 'in hand' you pop elements off the stack as dictated by the signature. Yes, exactly. Maybe an example makes that clearer (other than the example linked...

> and that we should hold off on any sort of memory-to-record operator that is analagous to memory-to-string (or read-utf8 or whatever we end up calling it) for now Strongly...

Though I think we should support using WebIDL as a unified call-to-arbitrary-JS API. And for passing an arbitrary JS object, using `as webidl-type=any` should result in a wasm `anyref`. My...

We explicitly want to avoid exporting things the module author doesn't want public. The use case for the core/interface export distinction is because many adapter functions will want to interact...

I was predicting a pattern more like ```js const { wrapIfNeedBe } = await import("./glue.js"); const { instance } = await wrapIfNeedBe(WebAssembly.instantiate(/*...*/)); instance.export.highLevelFunction(); ``` but it's likely that we'll see...

Would it be able to use the record types directly from core-wasm, or just at the IT layer? Because I interpret this question as being about "how do core wasm...