Tracking issue for ? operator (RFC 243, question_mark)

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

See also the related tracking issue for try_trait_v2, #84277 (rust-lang/rfcs#3058)

"Try Blocks" (try { ... }) were previously tracked here, but moved to #154391

For heterogeneous try bikeshed MyType blocks, see #149488

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
  - add test for try-block-in-match-arm #120540
  - Add another *ExprWithBlock* test for try blocks #148968
- Address issues with type inference (try { expr? }? currently requires an explicit type annotation somewhere).
  - Implement the alternative try block desugaring #148725
  - Add homogeneous_try_blocks RFC rfcs#3721
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

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.

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

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

@reem

@reem

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

Please do!

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

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?

}

@petrochenkov

@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.

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.

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

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

@bluss

@bluss yeah, I admit none of them are great... override seems like the only one that is close. Or we could use do, heh. Or a combination, though I don't see any great ones immediately. do catch?

Rollup merge of rust-lang#148725 - scottmcm:experiment-new-try-block-…

Rollup merge of rust-lang#153445 - ia0:overflow_try, r=ytmimi

Unrolled build for #153445

Rollup merge of #153445 - ia0:overflow_try, r=ytmimi

Thanks for over 10 years (😮) of discussion on this issue! With the new RFC (rust-lang/rfcs#3721) merged, I'm going to move the try { ... } tracking to a new issue, #154391

(Not closing now as the tracking issue number in source needs an update first.)

Rollup merge of rust-lang#154409 - scottmcm:change-try-tracking, r=Ta…

Rollup merge of #154409 - scottmcm:change-try-tracking, r=TaKO8Ki

Rollup merge of #153445 - ia0:overflow_try, r=ytmimi

Navigation Menu

Repository navigation

Tracking issue for `?` operator (RFC 243, `question_mark`) #31436

501 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for ? operator (RFC 243, question_mark) #31436

Description

Activity

reem commented on Feb 5, 2016

nikomatsakis commented on Feb 5, 2016

glaebhoerl commented on Feb 5, 2016

petrochenkov commented on Feb 5, 2016

thepowersgang commented on Feb 6, 2016

petrochenkov commented on Feb 6, 2016

eddyb commented on Feb 6, 2016

petrochenkov commented on Feb 6, 2016

durka commented on Feb 6, 2016

bluss commented on Feb 6, 2016

durka commented on Feb 6, 2016

501 remaining items

scottmcm commented on Mar 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for `?` operator (RFC 243, `question_mark`) #31436