Please tell me 'yeet' is not a thing in Rust!

I woke up this morning to find Youtube offering me this video on Rust error handling: A new way of error handling in Rust - YouTube.

Jees is that hideous. Is Rust about to grow its first monstrous carbuncle?

I mean 'yeet' is not even a word. Well, apparently some slang that people have used some place some time. And it reads and sounds horrible.

If we do really need a "yeet" could we use some existing, well known, word that means about the same (as far as I can tell). For example 'lob'. As in "lob a hand grenade".

3 Likes

AFAIR it's a stand-in for whatever term bikeshedding might eventually converge to.

2 Likes

Yeet is Old English for "Yeet, I can't be bothered to write return Err(…)".

14 Likes

It's a placeholder:

It currently exists experimentally and likely needs an RFC before stabilization -- at the very least it will not stabilize under the name Yeet .

6 Likes

Actually, that statement is now too weak. Lang has updated the process so it cannot go further than experimentation without an RFC now.

(I've updated that tracking issue.)

@ZiCog see https://areweyeetyet.rs/ for the history.

13 Likes

It appears in the online editions of the Cambridge, Merriam-Webster, and Collins dictionaries. Possibly in recent print editions? It is as much a word as any other.

11 Likes

Since this is getting upvoted, I can't help but point out that it's missing the point. I'm pretty sure the intention behind the OP wasn't to claim that this word doesn't exist. See e.g. this comment on the issue:

The problem is not that it isn't in Merriam-Webster; the problem is that it's inappropriate.

9 Likes

The point is just to use a word has a similar meaning to throw or raise so we can try out the idea without getting bogged down by syntax, but make it something so ridiculous that there is no chance it'll ever be standardized.

18 Likes

Given the context in which yeet appears, I've never really had a problem with the word TBH. Is it intended as a placeholder to avoid useless bikeshedding? Most probably. Is it unusual? Definitely. Does that make it inappropriate? I'd argue not as such.
It also made me laugh when I first read the proposal, and lacking any technical reasons to remove/change it (most reasons I've read so far are social rather than technical) coupled with throw, raise etc being problematic for their associations with exception handling, I figure it's about as good a word as any for the purpose. Certainly better than toss.

7 Likes

Can someone explain to me its usefulness?
So far I have only seen examples like

yeet MyCustomError

instead of

return Err(MyCustomError)

It seems like so little improvement. Is there more to it?

4 Likes

I believe try { yeet MyCustomError } will return Err(MyCustomError) from the try block (currently unstable) unlike return Err(MyCustomError) which will return from the current function.

8 Likes

I don't know how it works in the current implementation, but I would expect it to work like Err(E)? or anyhow::bail!(..). That is, you can yeet an error of a more specialized type, which will be converted to the expected error type of the try block. Moreover, try blocks are not just about Result<T, E>, but about any type which implements the Try trait. This means that you could e.g. yeet an error, which is converted to MyTryType<T> in some way.

Not that I am advocating for its addition to Rust, but yeet is in pretty common use among younger people. I even use it somewhat flippantly from time to time. There's nothing wrong with a bit of humor in design. If being professional means always being boring, stuffy, and inflexible, then I never want to be professional.

9 Likes

That's right. If you're only dealing in Results, then do yeet e is roughly the same as match Err::<Infallible, _>(e)? {} right now.

(If you're wondering why there's a match there, it's because Err(e)? isn't known to diverge, but yeet is.)

EDIT: Hmm, I guess the match phrasing isn't quite right either. So I guess do yeet e is more like { let unreachable = Err(e)?; #[allow(unreachable)] { return unreachable; } }.

4 Likes

yeet is not an improvement, not even a small one.

In ancient times, we were throwing exceptions left and right and catching them (or not), because we didn't know any better. But since then, we realized that throwing/raising exceptions/errors/whatever was a bad idea except for fatal cases resulting from bugs or unrecoverable conditions where the wisest choice is to shut down the entire process, or at least some well-contained set of threads.

Python, Java, C, C++ still do it, because they are dinosaurs, but modern languages try to avoid it.

Rust does the only wise thing: for fatal conditions we have panic, and for recoverable stuff we have things that can go with ?.

Considering that panics are the closest equivalent to exceptions, any word that alludes to "throw" or "raise" would logically correspond to panics, not to types that can do ?.

Besides, when people like to throw exceptions, they like it because they can throw a variety of things without changing the function signature, and they can choose where to catch it, or choose not to catch it at all. None of that would be true for yeet.

8 Likes

.
But we already have one keyboard which can return value from expression: break. It can return value from loops and now from normal blocks, too.

Why do we need another keyword with very similar semantic just for try blocks? Why just not reuse break and write break Err(MyCustomError).

Yes, it's a bit more typing, but doesn't introduce any new concepts and any new keywords.

4 Likes

So this is yet another way to implement GOTO in a structured programming language :slight_smile:

1 Like

For the same reason that we have return instead of break 'fn: it's clearer when separate concepts have separate syntax. Otherwise it's harder to both write (because you'd have to always make up tons of labels) and read (because you never know where you return until you track all labels).

Also, if yeet would use `break 'try_label' syntax, I could write this:

'external: try {
    'internal: try { break 'external () }
}

which doesn't make sense, you can't jump across several try blocks at once. So you can write it, but just always get an error.

Finally, with break it would be unclear what should be the type of returned value. For Result<T, E>, should you return T? E? Always Ok(T)? Always Err(E)? Mix and match them? It's not intuitively clear and would just cause confusion.

And if you return an error, you can't just apply error conversion in break (because no other break does it). You'd have to do error conversion manually, which would be error-prone and super boilerplaty.

Sorry, but I don't buy it.

When they are separate. I don't see it that way. In fact I would have liked your break 'fn (and also break 'try and, maybe, break 'if) better than current return.

But return have extremely strong reason to exist: almost all curly-bracket languages (and many non-curly-bracket ones) have this operator.

That's the most compelling reason to have both return foo and also break 'label foo (I would have like return 'label foo better, but that ship have sailed).

yeet doesn't have such advantage: it doesn't exist in any modern language and, in fact, I don't even remember any language where construct like proposed yeet exists.

You have already shown how to solve that issue: if break 'try would be usable in many try blocks (by just picking the innermost one) then you would only need labels for nested ones.

To me that makes perfect sense and yes, indeed, I would expect that code to work. Why shouldn't it work? It does work with nested try blocks and normal break.

It's perfectly clean if you don't introduce any “simplifications” and just make 'break return actual value.

Yes, it may not be as pretty, but, presumably, you are not using try just to then explicitly return errors from it. You don't need any syntax sugar for that. yeet/break/whatever is not supposed to be used often, if I understand the whole thing correctly, which means that the less magical it is the less confusing the whole thing becomes.

Adding one .into() is not considered a big problem in Rust in many other cases, why this one is special?

P.S. I, kinda, understand why Rust can not just embrace monads, but their repeated reinvention is just tiring.

3 Likes

Yesterday, at a friends house, I was not being too social, nose in my phone, reading this thread.
Someone called me, brought me back into the group, said for me to get off of facebook.

So anyway, I said, "Does anyone know what 'yeet' means?" And everyone knew. They said, "Yeah to throw something away from yourself." and I was the only one that didn't know the word.

Thank you again to the Rust team getting me to learn something new.

9 Likes