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 :)