In this design meeting there was a discussion about the syntax to use for returning early with an error. The considered keywords were
yeet. I couldn't find any more recent discussion.
Essentially, this is syntactic sugar for
Err(...)?, except that it should work for any type that implements
Try, not just
Many crates have a macro called
bail! for this, so a
bail keyword is out of the question, since it would cause a lot of churn for these crates.
raise are associated with exceptions, which Rust doesn't have, so these names are suboptimal.
fail has the disadvantage that it implies an error, but the keyword should work for any type that implements
Try, so the type that is returning early isn't necessarily an error. I'm not sure what
yeet is supposed to mean, I guess it's a made up word.
I think that it's time to decide now, because if we want a keyword for
Err(...)?, that keyword requires a new edition, and the next edition is approaching fast.
After a bit of brainstorming, I came up with a few more candidates:
I particularly like
excuse, but I'd like to hear more opinions and suggestions.
The design I had in mind doesn't work with the new Try trait proposal as pointed out by @steffahn. So if we want this feature to be generic over the new
Trytrait, that could be done with a new-type, here called
yeet foostatement could be desugared like so:
// with the current Try trait: return Try::from_error(From::from(foo)); // with the proposed new Try trait: return FromResidual::from_residual(Yeeted(foo));
The desugaring would be special-cased in
tryblocks, so we only exit the
tryblock and not the whole function.
Yeet is a slang phrase meaning to throw with force.
yeet;can be syntactic sugar for
Instead of a keyword, this could be implemented as a function:
A keyword can't be reserved before the RFC for that keyword is accepted, so the
yeetkeyword (or another one) most likely won't make it into the 2021 edition
The motivation for this feature is not entirely convincing
Apparently there's a Grand Evil Plan to make
breakwork everywhere and make
returnsyntactic sugar for
break 'fn. While the merit of that is unclear, it would be useful to be able to
breakout of a
bail!macros in common error handling crates don't work as one would expect within try macros (they return from the function). But it would be possible to rewrite them to use
Err(...)?currently triggers a clippy style warning, except in
tryblocks. However, that warning could be disabled if desired.
Exiting a scope and value wrapping are two orthogonal concerns, so they arguably shouldn't be combined with a single keyword.
You may edit this summary.