Tracking issue for RFC 2388, reserve the try keyword and resolve do catch { .. } syntax question with try { .. }

[Centril]

This is a tracking issue for the RFC "Reserve try for try { .. } block expressions" (rust-lang/rfcs#2388).

This issue only tracks the keyword reservation in edition 2018,
and renaming do catch { .. } to try { .. }.
For the main issue, see #31436.

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?
  cc @Manishearth, @scottmcm )
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)
  • note: stabilization of try { .. } is tracked via Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436.
• Lint for usage of try as an identifier
• Ensure that try { .. } $ident { .. } does not parse
  (so that we have options for try { .. } catch { .. }).
  • Tracked in Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436 instead

Unresolved questions:

• Should try!(expr) still work in edition 2018+? If so, how exactly should it?
  Resolution: it should not.

[kennytm]

Ensure that try { .. } $ident { .. } does not parse (so that we have options for try { .. } catch { .. }).

Huh this is not mentioned in the RFC at all.

(Currently do catch { stuff } $ident { ... } won't typecheck because () is not Try)

[Centril]

Huh this is not mentioned in the RFC at all.

It's discussed in the RFC comments tho :) This is just future proofing.

I'm not saying we should necessarily add catch handlers, but if we let try { .. } catch { .. } parse and stabilize it as such, then afaik you forfeit the ability to add catch / match / else / .. after.

But if we can solve the struct catch; try { .. } catch { .. } problem by not letting () implement Try then I suppose you future proof that way too?

[est31]

Where is the part that the try macro should still be allowed? What happened to that?

[nikomatsakis]

As I mentioned to @est3I believe that we ought to be able to support try! as a kind of "special case" in the parser. Seems worth adding as an unresolved question, at least (this would basically be a kind of contextual keyword). I'd still however prefer that in Rust 2018 try! the macro is deprecated (and warns you, suggesting a rewrite to use ? -- though perhaps not a "rustfix-enabled" rewrite). At minimum I suppose we can rewrite to r#try!(...).

[Centril]

@nikomatsakis

Seems worth adding as an unresolved question

Done :)

[Centril]

cc @Manishearth on try! in edition 2018.

[scottmcm]

@Centril I think work here is currently blocked on #50307

[est31]

Very interesting cpp proposal just as this RFC wants to bury try!(expr): they want to add try expr expressions.

A big point for this RFC was familiarity with other languages. Now as finally other languages are becoming familiar to us we get rid of those now familiar components and adopt their legacy idioms. This isn't really good.

So why not be consistent with Cpp here and adopt their try expr expressions? Then instead of try!(expr) and expr? you could write try expr, just like that Cpp proposal says.

[scottmcm]

@est31 That paper is consistent with this RFC's use of try, as its try expressions are still marking areas in which exceptions are possible, not every call which can throw. From 4.5.2 (p38):

try return “xyzzy”s + “plover”;             // ok, covers both “”s and +
return try “xyzzy”s + “plover”;             // same

If it were like ?, then it'd need to be this other example from the section, but it's explicitly not needed

return try ((try “xyzzy”s) + “plover”);     // ok, but redundant

Overall, the paper's try expr feels more like the Automatic “?” inside try {…} blocks IRLO thread.

[alexreg]

I'm yet to see a good explanation of the semantics of all this try business... it looks nasty to me, but what is it?

[Nemo157]

@alexreg see "catch { ... } expressions" on the other tracking issue linked in the OP, this issue is just about renaming those from their current implementation of do catch { ... } to try { ... }.

[alexreg]

@Nemo157 Okay, that makes the semantics of try { ... } clear, but I still don’t get what try { ... } catch { ... } should do...

[cramertj]

@alexreg catch { ... } wouldn't exist, only let _: Result<...> = try { ... };

[alexreg]

@cramertj Oh good. Just scoping of the ? operator in other words? Changing its exit behaviour.

[glmdgrielson]

Wait, why does this need to be an unconditional keyword? I'm a bit uncomfortable about this since this means that code somebody just copied may break when pasted into a new file for no obvious reason. Why can't we handle it like union? What's the difference?

[kennytm]

@glmdgrielson See the discussion in #31436. In short,

struct try { a: Option<u32> }

let a = Some(1);
let b = try { a }; // is this a `try` expression or a struct literal?

[scottmcm]

@glmdgrielson The difference with union is that it's always followed by an ident, so it can be disambiguated with one token of lookahead, since ident ident is never a valid expression. And that's helped by the fact that union is an item, so in most places it's obvious, since .union or (union or similar can't be items and pub union (or just union outside a fn) can't be an expression.

[scottmcm]

Added this to the edition milestone for tracking purposes, since this issue is all about restricting in the edition. (For extra clarity: stabilization of the feature is #31436, which is not part of the edition.)

[SimonSapin]

I was mislead by the title of this RFC. I thought it was only about reserving the keyword to have another option available for a later decision. The title should have indicated that it also makes a "normative" change to syntax introduced in a previously-accepted RFC.

[pnkfelix]

visted for T-compiler triage. It seems like progress here has ... stalled? Does someone own the remaining steps here, given that it is on the 2018 Release Milestone?

[pnkfelix]

also, tagging as P-high

[Centril]

@pnkfelix I believe that everything edition sensitive has been done wrt. keyword reservation and such.

[scottmcm]

I've checked the checkboxes above:

• try is mentioned as a 2018+ keyword in https://doc.rust-lang.org/nightly/reference/keywords.html; are there any other doc updates needed for this issue?
• I don't think there's a "Stabilization PR" for this, since the stabilization will be of the larger feature? (That or it's already happened, since let try = 4; already fails in 2018.)
• Linting for try as identifier seems to have happened in https://github.com/rust-lang/rust/pull/53685/files#diff-832e2b9b4fa0dcfe0f517f9b6f3b0be3
• The future-proofing parse code is not in, but that only blocks stabilization of the Tracking issue for RFC 2388, reserve the try keyword and resolve do catch { .. } syntax question with try { .. } #50412, which also has a checkbox for it, so it's not needed here.

So I think we're good to close this one?

[Centril]

@scottmcm yeah I think we can close it... should we perhaps open a new tracking issue for try { ... } ?

[viper6277]

As I mentioned to @est3I believe that we ought to be able to support try! as a kind of "special case" in the parser. Seems worth adding as an unresolved question, at least (this would basically be a kind of contextual keyword). I'd still however prefer that in Rust 2018 try! the macro is deprecated (and warns you, suggesting a rewrite to use ? -- though perhaps not a "rustfix-enabled" rewrite). At minimum I suppose we can rewrite to r#try!(...).

Newbie here....So ...how do I replace ?

r#try!(m.add(py, "test", py_fn!(py, test())));

[cramertj]

m.add(py, "test", py_fn!(py, test()))?;

[viper6277]

m.add(py, "test", py_fn!(py, test()))?;

Thanks @cramertj .... run into these syntax issues all the time with rust, but I still love what the language is about, ... I've become a huge rust fan and plan on sticking with it.