Francis McCabe
Francis McCabe
There is an agenda item in the 11/04/24 meeting of the stacks subgroup that refers to this issue.
The primary requirement is that you are a member of the CG. However, we often have visitors; so you can join as a visitor (if you are not a member...
A follow up: it seems that all other WebAssembly.RuntimeErrors represent non-recoverable situations (i.e., traps). I also do not feel that issuing a JavaScript TypeError is appropriate for this situation. So,...
It is still a 'first'. But, better than using RuntimeError.
Have landed change to spec (&V8): we throw a SuspendError instead of trapping.
I do not follow this argument. There is no requirement that the wrapper be suspendable. The requirement is to polyfill the API.
According to [this](https://www.w3.org/2001/tag/doc/promises-guide#accepting-promises), an API is expecting a Promise should always resolve the value. This seems to imply that wrapped imports should always suspend.
We are getting to the point where we need to make a decision on this. At the moment, I see the arguments as pro: 1. requiring a Promise from wrapped...
This is resolved in favor of resolving inputs of wrapped imports. I.e., use Promise.resolve on result of call to import; this coerces the value to be a Promise (or then-able)....
Am reopening this issue. The original motivation for performing the equivalent of Promise.resolve on the result of a call to an import was to follow W3C TAG guidelines about Promise-bearing...