Clarify `if_except` text format

[binji]

The if_except format is described like this:

if_except block_type except_index
  Instruction*
end

But this doesn't include the optional label, which all other block types have. Assuming that comes first, as with others, it should be:

if_except label_opt block_type except_index
  Instruction*
end

This introduces a slightly tricky parse:

(except $e i32)
...
if_except $e
end

In this case, $e is the exception index, but that's not known until end, as it could be the label name.

It's not too hard to make this parse, but I wonder if it would be better to put the exception_index first instead to simplify things.

[KarlSchimpf]

Yes, these instructions can have labels. They weren't listed in the proposal because the design document did not have labels. I tried to follow the same format.

I also see how it could be better to move the the exception index first. Updating the document to match.

[rossberg]

Label and block type are first everywhere else, so I wouldn't do it differently here. I guess it's kind of ugly either way.

[binji]

OK, here's another alternative. Keep the except_index last but use a prefix (like align=) to signify:

if_except except=$e
if_except (result i32) except=$e
if_except $label (result i32) except=$e

I don't really like this, but maybe it'll give someone else a better idea. :-)

[eholk]

What about this?

if_except label=$label (result i32) $e

It totally breaks convention, but it puts the prefix on the optional part rather than the required part.

[rossberg]

The convention for binding occurrences of identifiers is that they always go directly after the keyword of the construct that binds them. So I don't know about the label= thing -- it doesn't even look like a binding occurrence. ;)

OTOH, the x= convention so far is only used for optional attribute immediates, so the except= use doesn't quite fit in either.

I'd just go with the plain thing, label_opt blocktype index. It may look a bit weird in some of the cases, but I don't think it's ambiguous, so no strong need to go out of our way to invent something new.

We should come up with a better name for this instruction, however! The name if_except obscures that it pushes operands to the body. I think handle would be quite fitting.

[eholk]

I'd like a better name too. 'handle' is growing on me. What about something like exception.handle or exception.match? I kind of like the idea of giving most or even all of the exception instructions a prefix that makes it clear they're all part of the same proposal/feature set.

[binji]

We want something that still makes sense with then and else. I think exception.match does, but I think exception.handle doesn't quite as much.

[rossberg]

@eholk, hm, we haven't used prefixes on any control flow construct; tbh it looks weird to me.

@binji, I see what you mean. Doesn't sound too bad to me, but I'm not a native speaker. :) However, we may want to reserve "match" for something less exception-specific (e.g., unions/variants).

[binji]

I suppose it's not too awkward. "Handle this or else"!

[eholk]

I've been saying match in most of the discussions around the office, but I agree that I'd rather save it for something more general than just exceptions.

[aheejin]

We now have br_on_exn instead, so closing.