Description
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 mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- 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.