exception-handling
exception-handling copied to clipboard
WebAssembly
Moving WebAssembly.Tag.type to type reflection?
Are there known use cases that require WebAssembly.Tag.type to be part of the exception handling proposal? If not I would be in favor of moving it to the type reflection proposal.
The argument is that exception handling has more support and is advancing faster, so we should not make it depend on a less mature proposal. In particular if changes are made to the type reflection API later, it might be too late to reflect these changes in WebAssembly.Tag.type without breaking backwards compatibility, and would introduce inconcistencies. The two proposals are technically both at phase 2, but AFAIK type reflection is much less active, and exception handling is close to reaching phase 3 and 4.
cc @gahaas who pointed this out to me.
WebAssembly.Tag.type() should only be implemented if the engine implements both exception handling and type reflection. I don't really care what document it lives in; I think type reflection should be ready for phase 3 already and probably phase 4 soon as well.
I agree that this should only be enabled if both are supported. I am not sure how proposal intersections are usually handled, but I read the current explainer as though this was an unconditional part of exception handling. If we just agree informally here that this is not the case, that's fine with me and I think we can close this.
Unfortunately it looks like the inclusion of this method in this spec, and the WPT tests for it, has caused confusion among implementers. According to wpt.fyi, both Firefox and Safari are currently shipping the type accessor. Not yet sure what I think the right resolution is but something to keep in mind as we think about how to handle the type reflection proposal.
@eqrion @justinmichaud @codehag @SPY
Are you sure you're reading that correctly? Those results seem to be for nightly versions, which also ship the rest of the type reflection API. In any case, thanks for reminding me that I should remove it before we ask for phase advancement.
Thanks for pointing out the version skew. Updated wpt.fyi results show stable Firefox correctly avoiding exposing type, but with stable Safari shipping it. I don't have Safari in front of me right now so can't comment on whether they also ship the rest of Type Reflection, hopefully @justinmichaud can shed some light.
Based on https://wpt.fyi/results/wasm/jsapi/global/type.tentative.any.html?label=master&label=stable&aligned&view=subtest , it seems like stable Safari ships everything, yeah.