Add yeet experimentally

[scottmcm]

Proposal

yeet is a bikeshed-avoidance name for "fail, raise, throw, etc". It will not be the name anywhere other than in nightly.

The idea of an expression for returning with an error has a long history in Rust, going back to at least 2015, when it was mentioned in RFC0243, and probably earlier. It's repeatedly come up in various forms since then, such as failure::bail!, or more recently as yeet.

I propose that we allow it on nightly with an obviously-placeholder syntax to experiment with semantics, and ensure that our other language/library choices stay on a path compatible with it, until a decision is made to not want it.

This would be particularly helpful now as libs-api is looking at rearranging the try-related traits and lang is hoping to make progress on try{} stabilization. The MIR interpreter might be interested in experimenting with this as well, given it's currently using a number of throw!-like macros.

Impact on compiler

It's not clear to me that this strictly needs an MCP, since it doesn't "require updates to the rustc-dev-guide or the rustc book". But it does need a new ExprKind in the AST, so I figured I'd file the MCP for safety.

Like ? and try{}, this disappears in AST -> HIR lowering, so the impact is limited to the parser, the AST, and that lowering. Importantly, it does not require any changes to things like the type system or MIR.

I've tossed together an MVP of the feature (parsed, lowered, feature-gated, tested, etc) if you'd like to see the rough impact: scottmcm/rust@do-yeet

Goals

• Validate a lowering to trait method calls
• Ensure other features like try{} are forward-compatible with it
• Get experience reports about using dedicated syntax vs approaches like Err(e)?
• Have as little of the compiler care about this as is reasonable

Non-goals

• Have perfect syntax
• Pick a keyword
• Decide that rust should have this

AKA this work does not in any way replace a lang RFC, which would still be needed to make final decisions before this could even start towards being considered for stabilization.

Mentors or Reviewers

I don't know who would be a good reviewer for the compiler/ changes. Personally I found it fairly straight-forward to implement, as it behaves very similarly to break expr/yield expr/return expr in the parser portion, and lowers in a similar-yet-simpler way to ? in the semantics.

I suspect @yaahc would be willing to review any library/ changes needed.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[scottmcm]

Attempting to poke @rustbot ...

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[scottmcm]

Based on feedback from oli in Zulip, I'll close this in favour of rust-lang/lang-team#160