Tracking issue for `?` operator and `try` blocks (RFC 243, `question_mark` & `try_blocks` features)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#243 and rust-lang/rfcs#1859.

Implementation concerns:

• ? operator that is roughly equivalent to try! - implement the ? operator #31954
• try { ... } expression - implement catch expressions #39849
  • resolve do catch { ... } syntax question
    • Resolved as try { .. }, - Tracking issue for RFC 2388, reserve the try keyword and resolve do catch { .. } syntax question with try { .. } #50412
  • resolve whether catch blocks should "wrap" result value (first addressed in catch blocks are not Ok-wrapping their value #41414, now being settled anew in Resolving Ok-wrapping for try blocks #70941)
  • Add a test confirming that it's an ExprWithBlock, so works in a match arm without a comma
  • Address issues with type inference (try { expr? }? currently requires an explicit type annotation somewhere).
• settle design of the Try trait (extend ? to operate over other types rfcs#1859)
  • implement new Try trait (in place of Carrier) and convert ? to use it (Lower ? to Try instead of Carrier #42275)
  • add impls for Option and so forth, and a suitable family of tests (Impl Try for Option #42526)
  • improve error messages as described in the RFC (Improve ? error messages per RFC 1859 #35946)
• reserve try in new edition
• block try{}catch (or other following idents) to leave design space open for the future, and point people to how to do what they want with match instead

[reem]

The accompanying RFC discusses a desugaring based on labeled return/break, are we getting that too or will there just be special treatment for ? and catch in the compiler?

EDIT: I think labeled return/break is an excellent idea separate from ? and catch, so if the answer is no I will probably open a separate RFC for it.

[nikomatsakis]

Labeled return/break is purely for explanatory purposes.

On Fri, Feb 5, 2016 at 3:56 PM, Jonathan Reem notifications@github.com
wrote:

The accompanying RFC discusses a desugaring based on labeled return/break,
are we getting that too or will there just be special treatment for ? and
catch in the compiler?

—
Reply to this email directly or view it on GitHub
#31436 (comment).

[glaebhoerl]

Another unresolved question we have to resolve before stabilizing is what the contract which impls of Into have to obey should be -- or whether Into is even the right trait to use for the error-upcasting here. (Perhaps this should be another checklist item?)

[petrochenkov]

@reem

I think labeled return/break is an excellent idea ... I will probably open a separate RFC for it.

Please do!

[thepowersgang]

On the subject of the Carrier trait, here is a gist example of such a trait I wrote back early in the RFC process.
https://gist.github.com/thepowersgang/f0de63db1746114266d3

[petrochenkov]

How this is treated during parsing?

struct catch {
    a: u8
}

fn main() {

    let b = 10;
    catch { a: b } // struct literal or catch expression with type ascription inside?

}

[eddyb]

@petrochenkov Well, the definition couldn't affect parsing, but I think we still have a lookahead rule, based on the second token after {, : in this case, so it should still be parsed as a struct literal.

[petrochenkov]

Also

let c1 = catch { a: 10 };
let c2 = catch { ..c1 }; // <--

struct catch {}
let c3 = catch {}; // <--

+ rust-lang/rfcs#306 if (when!) implemented.
It seems like there are no conflicts besides struct literals.

Given the examples above I'm for the simplest solution (as usual) - always treat catch { in expression positions as start of a catch block. Nobody calls their structures catch anyway.

[durka]

It would be easier if a keyword was used instead of catch.

[bluss]

This is the keywords list: http://doc.rust-lang.org/nightly/grammar.html#keywords