Eric Holk
@Mark-Simulacrum - That's a good idea, I'll put up a PR documenting the current rules and then rebase this one on top of that so that the differences are clearer.
I just pushed #1093 which documents the current behavior. This PR now includes that one as well, so once we merge that one it will be easier to see what...
I added a couple more examples, one that's a slightly more complex version of the previous example, and another that shows a small change to remove a borrow from the...
If I understand your proposal right, it sounds like implementations would check the required features section and if the module declares it needs features the implementation doesn't support, the implementation...
> the key bit for me is that "stakeholders" sounds like a closed set One of the things I thought when I read the part that says "we welcome design...
This sounds like something that [safe transmute](https://github.com/rust-lang/project-safe-transmute) might help with if/when that becomes a thing. In the meantime, perhaps the [zerocopy](https://docs.rs/zerocopy/latest/zerocopy/index.html) crate would work? Although, it looks like zerocopy is...
This came up in one of the planning meetings recently. It was @estebank that [suggested this](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/sprint.20planning.202021-09-16/near/253609719). This initiative is not currently being worked on, but I thought it'd be good...
It seems like there might be some value in making program-generated exceptions different from errors we've currently defined in the spec. Would it make sense to add `WebAssembly.ProgramException` or `WebAssembly.UserException`...
Another issue we need to hash out is whether hosts can inspect values associated with Wasm exceptions. In the case of JavaScript, how should we represent `i64`s that are thrown...
Given that we have the precedent of not being able to call functions with `i64` in their signature from JS, I think it makes sense to do a similar restriction...