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

[Fishrock123]

So after reading the small pile of RFCs which are in one way or other related to this feature (but not well linked from the OP) (probably because the OP outdates some of these):

• 0243: Original exceptions RFC including ? and catch { }
• 1859: Try trait v1 (which doesn't seem to mention try blocks at all)
• 2388: The try { } expression name reservation
• 3058: The v2 Try trait and FromResidual
• Edit: Also "Resolving Ok-wrapping for try blocks" (Issue 70941)

There doesn't seem to be any comprehensive reference for try { } blocks. The original RFC is very light on specifics regarding catch { }, the try expressions RFC only deals with the naming, and the try trait v2 RFC leaves it to another RFC.

From the try trait v2 RFC:

So a future RFC could define a way (syntax, code inspection, heuristics, who knows) to pick which of the desugarings would be best. (As a strawman, one could say that try { ... } uses the "same family" desugaring whereas try as anyhow::Result<_> { ... } uses the contextual desugaring.) This RFC declines to debate those possibilities, however.

So it seems to me that the best way to move forward here would really be to make a dedicated try blocks RFC where a reference can be made for what the implementation should conform to, and try to make a direction for how to handle the inference problems, as well as documenting which concerns actually need to be figured out before stabilization and which can be left for future possibilities.

Maybe that's a bit heavy handed, and perhaps people don't think that's necessary but that's probably the direction I would opt to take before wanting to make PRs to adjust the compiler inference for try blocks in specific... if no one directs otherwise an RFC is what I plan to do...

Edit: It seems I missed the try-blocks Zulip discussion from 2022:

In the top of that thread, scottmcm says:

The problem is that I think the vanilla form (of try blocks inference) should do something different, which isn't a backwards-compatible change.

I've got an RFC started; ...

For those who don't want to dig into the thread, there was a draft at https://github.com/scottmcm/rfcs/blob/try-again/text/0000-resolving-try-annotations.md#summary

[Kobzol]

I think that before another RFC, a useful step forward would be to summarize all the existing RFCs and discussions from both GitHub and Zulip in a single document, so that it is easier to see the status quo, and the unresolved questions and blockers.

[dev-ardi]

I think that before another RFC, a useful step forward would be to summarize all the existing RFCs and discussions from both GitHub and Zulip in a single document, so that it is easier to see the status quo, and the unresolved questions and blockers.

I don't agree. All of the discussion should happen here and all of the relevant points should be raised here. If anyone has heard of anything they might point to it but I don't think that it makes sense to require a document because nobody wants to go over all threads compiling information.

It is my understanding that the only question left is about the inference, and based on the general sentiment that's not a blocking issue.

I propose to stabilize!

[Kobzol]

Of course that no one wants to do it, it's a lot of work, but that's what it takes to move these big features forwars :) For a stabilization PR, we'd need to do that anyway, to summarize the current state and precisely specify what are the current unresolved questions, potential blockers and alternatives.

[CAD97]

@dev-ardi All of the discussion should happen here

Actually, no. Discussion should be linked into the tracking issue, but tracking issues are not intended to be where discussion takes place. From the current tracking issue template:

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

---

It was my understanding that try blocks without a "return type annotation" were weakly intended to move to "residual preserving" semantics before stabilization. But still separately from that, I expect stabilization of Try itself is blocked on improving documentation around the Residual type. (Personally, I wish "stem inter-conversion" hadn't been used for Poll and poll? had been ready!(poll) instead. Unfortunately, that's quite unlikely to be changed even over an edition.)

[Fishrock123]

I asked @scottmcm if he still wanted to pursue his RFC in the Zulip thread, but with no reply https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/try.20blocks/near/419566066

I think that before another RFC, a useful step forward would be to summarize all the existing RFCs and discussions from both GitHub and Zulip in a single document, so that it is easier to see the status quo, and the unresolved questions and blockers.

I'm pretty sure I already did what you are referring by summarizing the discussion in the comment above that comment?

Like I said, there isn't a clear design for what the feature should actually be; so honestly an RFC (or pre-rfc, or similar) - a "document", as you describe it, which I don't see why would be anything other than a RFC-like document. RFCs are for defining features with discussion.

[Sytten]

What are the blockers for stabilization right now? Does this need another RFC or can the initial implementation be added to stable?