WebAssembly
Move exception handling to phase 4
Exception handling has been voted to move to phase 4 (ref). This patch reflects that change in the feature tracker on the website. Thanks!
This one I think is actually going to take some more nuance. What the browsers have shipped already is actually not the full current spec, it's what the spec now calls Legacy Exception Handling (specified in a spec appendix). Probably for the purposes of the website I think it would make sense to treat this as 2 separate features (maybe called "legacy exception handling" and "exception references" or something like that. None of the browsers have actually shipped the latter yet, but Chrome and Firefox have implementations behind a flag that we could also document here.
That makes sense to me. Follow up question though: how should we treat legacy spec features? Would these also be considered tier 4 and therefore "stable" because they're part of this spec? Or should we perhaps put these in a new, separate section clarifying that it's considered "legacy" and should not be relied on?
I'm personally not familiar with the contents of the spec, nor did I attend the meeting in which the vote was held, so I don't really know how Legacy Exception Handling has been discussed.
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 way before phase 4.
We didn't discuss the legacy status in this meeting (it really was just an acknowledgement that we'd completed all the steps, and making the formal vote); the background, changing the proposal and handling the legacy spec was discussed previously on github and in the October meeting last year. We do want to encourage users to use the new spec if possible, and eventually will have toolchains default to using exnref; even though on the web, the legacy instructions will only actually be removed if usage gets sufficiently low, and that may never happen. I'm not sure having a separate section in this table is the right way to do that or not. For now, at least until exnref ships in some browsers, it probably makes sense to keep them together.
Legacy EH should definitely not be considered phase 4, since it never reached that state. And there is no obligation for engines to implement it — in fact, they are encouraged to not implement it.
Not sure how to represent that in the table. But if we include it at all, then I concur with @dschuff that it should be separate from the new proposal, and it should somehow clearly be marked as legacy (i.e., to be deprecated).
Perhaps it would be adequate to move legacy features to the very bottom of the table, since they are to be considered on their way out, not in?
