Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rbuckton opened this Issue Aug 3, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@rbuckton
Copy link
Collaborator

rbuckton commented Aug 3, 2018

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

This comment has been minimized.

Copy link
Member

littledan commented Aug 4, 2018

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

This comment has been minimized.

Copy link

hbarcelos commented Oct 16, 2018

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

This comment has been minimized.

Copy link

ckknight commented Oct 31, 2018

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

This comment has been minimized.

Copy link

hax commented Dec 18, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.