Record types and try-catch-on

[jensjoha]

I've asked in the chat as well. Posting here to make it easier to find if needed later.

Currently

void foo() {
  try {
    ;
  } on Bar {
    ;
  }

  on(a, b, c) {
    ;
  }
  on(1, 2, 3);
}

is a try statement, then a local function declaration named on taking 3 parameters, then a call to that local function.

With record types this will instead parse as a try statement with a on specificRecordType clause, then a function call.

Any input?

/cc @lrhn @munificent @eernstg

[jensjoha]

On and probably /cc @bwilkerson

[lrhn]

The general problem is that built-in-identifier type used to be unambiguous, and that our contextual keywords were only allowed in positions where they were unambiguous (just before an identifier).
With two adjacent identifiers separated by whitespace, the first one had to be either a type or a modifier, and since modifiers were built-in identifiers or contextual keywords (or reserved), they couldn't be the name of a type.

With records, the type can now start with a non-identifier, so "built-in-identifier type" doesn't have to be two adjacent identifiers, and same for a contextual keyword followed by a type, which means it becomes ambiguous with many more grammar productions.

At least, a lot of our keywords can only occur as keywords outside of function bodies, and are either required by the context or clearly distinguishable from alternatives (not occurring where any expression can also occur). So, this may be the only actual ambiguity. (But we should check.)

I'll (presently) suggest that we make on after try { ... } always mean the on keyword.
If you really, really need to call a function named on right after a try block, you'll have to add parentheses.
In practice that'll likely never happen. I found one instance of a method actually called on, and it's an instance method, so you'd only do on(args) inside a subclass. That doesn't happen after a }.

So, on being a contextual keyword would actually be enforced by the context, not just allowed. Should make parsing easier: Is parsing try, looking for on/catch/finally. If you find on, you don't even need to look ahead (to check that the next token is an identifier), you can just start parsing a type immediately.

[munificent]

I'll (presently) suggest that we make on after try { ... } always mean the on keyword.

+1. I'll update the proposal to make that explicit.

cc @leafpetersen @eernstg @jakemac53 @natebosch @stereotype441 @kallentu