3 ms·
One of the commits in one of the first MRs in this article shows an example of a legitimate use of `unwrap()`... pub fn new(mut streams: Vec<TokenStream>)
by cesarb 7y ago
One of the commits in one of the first MRs in this article shows an example of a legitimate use of `unwrap()`...
pub fn new(mut streams: Vec<TokenStream>) -> TokenStream {
match streams.len() {
0 => TokenStream::empty(),
1 => streams.pop().unwrap(),
_ => TokenStream::Stream(Lrc::new(streams)),
}
}
Since `streams.pop()` will never return `None` when `streams.len()` is `1`.
But I agree, most of the time using `match` (or its simplified form `if let`) or one of these combinators instead of `unwrap()` is better.
- asdkhadsj 7y agoAs a sidenote, I've been thinking about instituting an internal styling guide to discourage `unwrap()` in your scenario, in favor of `expect("impossibly missing")` or etc. The message helps a bit more, and I also want to avoid debug unwraps that were forgotten about. Though, the more I think about it the more a macro makes sense to me, purely for code search. If we used a macro, something like `impossible!(streams.pop())` then I can code search for `.unwrap` and `.expect`. Hmm
- rrobukef 7y agoA compiler error if the code cannot be eliminated during optimization. Kind-of hacky, but it could be valuable as a new function.