Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



As 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


A compiler error if the code cannot be eliminated during optimization. Kind-of hacky, but it could be valuable as a new function.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: