Consider removing tags from proposal

[eholk]

Recent discussions have revealed that the tag system we are currently proposing is not very useful for implementing exceptions in C++ via LLVM. While tools are certainly welcome to ignore tags entirely and use only catch_all, as #31 proposes, it seems that we should consider removing the tags portion of the proposal entirely.

As far as I know, we currently have no languages that are planning to use tags. This means we could be in the unfortunate position of requiring more complexity on the part of WebAssembly implementations for a feature that is unused. It seems better not to require this in the first place.

From a design standpoint, I like tags, and I can definitely see how they could be useful to some languages. If there are languages actively planning to use these features, we should pull the implementors into the design process to make sure we come up with something that meets their needs.

If we do not have current users for tags, I suggest removing them from the proposal. Ideally we would do this in a way that leaves the door open for them if they are needed in the future.

[rossberg]

The primary purpose of exception tags in Wasm is not to distinguish different exceptions within the same language (although you can use them for that, too), it is to distinguish exceptions from different languages.

Keep in mind that Wasm effectively is a multi-language environment, where calls and exceptions can potentially cross language boundaries in arbitrary ways. In such an environment a language implementation has to be able to reliably distinguish one of its own exceptions (and corresponding assumptions about associated data) from foreign ones. The only way to achieve that reliably in an uncooperative environment is through some generative naming mechanism.

In other words, C++ is a current user, and must remain so!

[eholk]

My understanding of the discussion on #31 and in-person discussions with @aheejin is that because C++ needs to ensure destructors run in the presence of all exceptions, and because LLVM does not distinguish cleanup code (i.e. the code that needs to run even in the presence of a non-C++ excpetion) from catch code, the current plan is to only generate catch_all clauses and then use some other mechanism (such as Itanium-style LSDA) to decide what type of exception it was.

[rossberg]

Even then you will still need to distinguish based on the tag (i.e., some separate matching mechanism would be needed).

[eholk]

I think the plan is to do something like having a global variable like is_cpp_exception that the C++ code will always set before throwing an exception. When using just catch_all, you don't get access to the tag anyway.

[rossberg]

How would that work? Your exception could fly through some other language's frame that catches it and throws one of its own. Where would you have a chance to clear your flag?

[aheejin]

@rossberg That's a good point... Then we are going to need instructions like match as Eric proposed in #30. I think it would be good to have an instruction like not_match as well, because from the C++'s point of view (and most of future target language's point of view) the important thing is to tell if this is "our" exception or not.

If there are another use cases, I don't particularly insist on removing the current catch tag instructions, but what I tried to convey in #31 is at least C++ cannot use it, because it has no way of separating cleanup code or catch (...) part of the code from a CFG.

[eholk]

This thread has given us a strong argument in favor of keeping tags. I think it also strongly suggests that we need a way to dynamically inspect an exception. Since we've now considered removing tags and decided to keep them, I'm going to mark this issue as closed.