Derek Schuff

regarding legacy features, EH is really an, um, exceptional case here. There aren't (and hopefully won't be in the future) other cases where a feature was shipped and then retrofitted...

This is now done in #390. Thanks for raising this!

I think it's a good idea to support this, but I also think it's best not to have it on by default. Not just for the surprise in possibly exposing...

Are you suggesting some change to the spec, or some change to a particular interpreter, e.g. the reference interpreter? The core spec itself tries to separate out everything about the...

IIUC this isn't about the filesystem API though, it's about how interpreters work (but unrelated to how they actually implement the wasm language). But the spec doesn't actually say anything...

Yeah we recently did a big merge of new features into the core spec, so it did get larger. Sorry about that 😆

The way to translate JS exceptions into wasm exceptions is to import the [JavaScript exception tag](https://webassembly.github.io/exception-handling/js-api/#js-exceptions). Then you can create a wasm catch with that tag, and when a JS...

You can pass any JS value as an `externref` into wasm (either by passing/returning it from a function, or catching it in wasm), and then you can throw it from...

Yes, all of that is true. I probably should have said that you can't get a *unique* exnref that corresponds to the original JS throw. Because the exnref is actually...

Wasm is really both a stack machine and a register machine. Locals are meant to be used by compilers more-or-less as registers are; and implementations typically treat them that way...