Proposal to remove unwind

[tlively]

unwind is similar to catch_all and in the semantics we've settled on it is also strictly less expressive than catch_all. unwind can be defined in terms of catch_all and rethrow, so any program that uses unwind could equivalently use catch_all and rethrow instead.

unwind was originally meant to be a forward-compatibility feature bridging the gap between the current EH proposal and some future proposal for additional non-local control flow. My personal concern about this is that we have not discussed making an exception to WebAssembly's usual backwards compatibility guarantees for unwind, and it is not possible to both maintain backwards compatibility and allow for a graceful transition to different (currently unspecified) semantics.

Since unwind does not increase the expressiveness of the proposal and does not seem useful for other reasons such as forward compatibility, I propose that we simplify the proposal by removing it.

Does that sound reasonable, @aheejin, @RossTate, @rossberg, and @ioannad?

[rossberg]

Thanks for bringing this up. Yes, that sounds reasonable to me. Any hypothetical addition of more forms of terminating non-local control transfer (if they're even desirable) would inevitably change the contextual observations of existing code, and thus invalidate assumptions it might have. Unwind can't prevent that -- nothing generally can AFAICT. But I don't think it ever was an assumption that this ought to be possible either. Combining code from different sources/runtimes will always require extra care and possible barriers, handling which is the purpose of e.g. the IT proposal.

Also, if we included a special feature along these lines, then it should at least be designed such that it can effectively express common constructs like finally clauses, with isn't the case with unwind (it would require code duplication that is exponential in the nesting depth of finally constructs). Otherwise, those constructs will likely be compiled to catch_all anyway, and any supposed forward compatibility is already moot.

Finally, unwind has unusual behaviour relative to the Wasm instruction set, since it would be the only block construct where end is not a control no-op but actually has rather non-trivial behaviour. That could be taken as an indication that there is a mismatch in abstraction level.

[lukewagner]

Oh good; I had only recently noticed unwind (having missed the rather long discussion leading up to it) and I had the same immediate concern. Introducing two ways of doing the same thing today and trying to make one of them behave differently in the future seems guaranteed to fail: if I can't write tests confirming I'm doing the right or wrong thing today, then there's no chance the whole ecosystem is going to get things right for a hypothetical tomorrow.

[aheejin]

I support it as well because of all the reasons I stated in the other discussion thread. I agree the peculiarity of end behavior is not very much in line with other wasm block-like instructions, and also we don't need to have two different ways to achieve the same thing in the current spec.

[eqrion]

SpiderMonkey would also be in favor of deferring unwind. Primarily concerned about the feasibility of changing the behavior of unwind in the future in an open-ended way and expected it to be used correctly today, as Luke mentioned.