News for hackers. Stuff that matters.
Re:Speeding Up the Rust Compiler by cesarb on Wednesday December 11, 2019 @07:31AM (#21761810)
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.

Re:Speeding Up the Rust Compiler by asdkhadsj on Wednesday December 11, 2019 @08:39AM (#21762189)
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

Re:Speeding Up the Rust Compiler by rrobukef on Wednesday December 11, 2019 @12:25PM (#21764630)
A compiler error if the code cannot be eliminated during optimization. Kind-of hacky, but it could be valuable as a new function.