Grammar: 'using () {}' vs 'try () {}'

[rbuckton]

Although there is a separate syntax discussion ongoing in #11, I'd like to have a separate discussion on the merits of aligning somewhat with Java's try-with-resources syntax:

// declaration head
try (const a = …) {
}

// expression head
try (expr) {
}

Note that Java also allows you to couple try-with-resources with additional optional catch and finally clauses:

try (const a = …) {
}
catch (ex) {
  // 'a' is already disposed and out of scope
}
finally {
  // 'a' is already disposed and out of scope
}

Which would be semantically equivalent to:

try {
  try (const a = …) {
  }
}
catch (ex) {
  // 'a' is already disposed and out of scope
}
finally {
  // 'a' is already disposed and out of scope
}

[littledan]

The choice here is similar to the match vs case decision for pattern matching. I think we should decide in general whether we are OK with adding this type of contextual keyword going forward, which involves more complex cover grammars similar to those added for async arrow functions. Cc @bakkot @waldemarhorwat

[hbarcelos]

Aside any grammar issues, I believe that adding new reserved keywords to a language should be done carefully.

For example, while adding async/await makes sense, since it's a change of paradigm, this proposal is only a glorified syntactic sugar. While I believe it has its value, I don't find it worthy of a new token in the language.

Also, this may not be a strong argument, but given Brendan Eich clear inspiration on Java for creating Javascript, sticking with the known try-with-resources Java pattern is better than introducing using.

[ckknight]

I think having try works because the addition of the parenthesized declaration, it's clear that it's doing something a little special that a regular try-catch or try-finally doesn't do. Assuming we can also bring along catch and finally semantics, as Java does in your example. It also brings the familiarity as well.

Given that this will work without conflict, as it doesn't introduce a new top-level syntax keyword, the only benefit I see to not using try would be to differentiate it from our familiar try-catch-finally blocks. Also, I could see myself wanting to put a try-catch around a using block in order to guard for certain errors, so that just makes me lean toward using the try keyword and allowing catch and finally.

[hax]

tc39/proposal-optional-chaining#77 also want try keyword 😉

[rbuckton]

Switched to try in #26.