A very typical use-case would be getting something from a HashMap (or a Vector) and calling unwrap because you know it must exist (as you got a reference to the index or object that must be valid in the HashMap or Vector).
Or if you call a function that returns Option<…> depending on the current state and you know that it must return Some(…) in the current situation.
I mean using unwrap is not bad practice if the value is guaranteed to not be none, which can happen frequently in some applications.
A good example would be regex. After validating it when writing the program it should always compile, although this could also be solved with a proc macro that validates the regex at compile time.
If it’s guaranteed to not be
None, why is it anOption?Here’s a bad example but hopefully captures the why. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=43d055381e7bb52569c339d4526818f4
We have a condition we know must be satisfied (the option will always be Some), but cant prove in code.
Oh, it can happen when you do calculations with compile-time constants…
But the GP’s claim that it’s a “frequent” thing is suspect.
(Crashing is also useful when you are writing and-user applications, but you’ll probably want .expect like in the meme.)
A very typical use-case would be getting something from a HashMap (or a Vector) and calling unwrap because you know it must exist (as you got a reference to the index or object that must be valid in the HashMap or Vector).
Or if you call a function that returns
Option<…>depending on the current state and you know that it must returnSome(…)in the current situation.