Hacker News Reader

The standard method name also makes it super easy to go back and tighten things up when the time comes

I recently had a nontrivial project where I'd used maybe a dozen unwrap()s in different places and had gotten a handful of bug reports for resulting panics. So I decided to make a pass and finally clean them up

Project-wide search for unwrap(), went through and properly handled all of them, very quickly and easily plugged all the holes, no more panics being reported

It's also something you can do static analysis for with tools, and I imagine the compiler can be adjusted to warn or disallow its use in modules and dependencies.

There is a problem here - it's verbose and prone to silent-ish breakage if the surrounding context changes e.g. due to refactors (well, probably not with this tiny example, but I hope you know what I mean). Thankfully, there is also a solution to this problem: https://github.com/rust-lang/rust/issues/90091

split_array will eventually allow something like the following, which avoids any explicit indexing and will fail to compile if the sizes don't match up:

    struct IVec2(i32, i32);

    impl IVec2 {
        fn parse(b: [u8; 8]) -> Self {
            let (first, second) = b.split_array();
            IVec2(i32::from_le_bytes(first),
                  i32::from_le_bytes(second))
        }
    }

I do appreciate that Rust tends to have the mentality that they will, after careful consideration, add something like split_array to solve X ugly problem.

But it leads to just a TON of features and approaches to learn.

> [...] well, probably not with this tiny example, but I hope you know what I mean [...]

Well, here's the thing. These small pieces of code DO show up in actual, real codebases! I've gotten feedback during code reviews along the lines of, "What if the surrounding context is refactored, this tiny, simple piece code could break" and to be perfectly honest, when I get it, I come down to your desk and we have a discussion about whether that kind of feedback is appropriate, and the purpose of code reviews.

(It also always seems like the issue I'm looking at is "fixed in nightly", but some of those features in nightly take a long time to get accepted, and the ergonomics of split_array() seem a bit dubious to me. Are you going to chain three split_array() for four fields? Obviously, for simple serialization and deserialization there are a ton of different options to automate this code away, but it's nice to be able to write simple code like this when appropriate, and the ergonomics of simple tasks matter.)

That's helpful for that one example, but it doesn't solve the general case. I can think of a hundred different examples that aren't handled by the type system or stdlib.

  fn high_word(n: u32) -> u16 {
      (n >> 16).try_into().unwrap()
  }

Unless someone manages to solve the halting problem, we'll always need unwrap() or equivalent.

Maybe the function unwrap should be renamed to ISolemnlySwearThisCanNeverFail.

We'd need an even more unholy name for `unsafe { foo.unwrap_unchecked() }`!

That’s a feature!

I’d be thrilled if C++ required wrapping declaration and use of global variables with ‘unsafe_and_evil { … }’

It's also the case that this call to `unwrap()` will be removed by dead code elimination.

See: https://play.rust-lang.org/?version=nightly&mode=release&edi...

Where if you look at the asm for playground::high_word then you'll see it's a bare shrl.

I'd quite like an analogue to unwrap() that's checked at compile time -- an out for the type checker, but an error if it's not dead code eliminated. This helps us to trust and rely on the compiler, and is the converse of `unsafe_unwrap`, which tells the compiler to trust us.

In this example you could do: (n >> 16) as u16

There is also this thing called "Infallible". Which will eventually be merged with "!". To express to the compiler and the programmer that something can never fail.

https://doc.rust-lang.org/std/convert/enum.Infallible.html

I think the idea is that `expect()` accomplishes the same thing, but allows you to put an explanation of why the function should be total (such that if it does indeed panic, you can see what went wrong with the reasoning).

That said, I do think there's a place for "unwrap" in eg. tests.

That seems even more verbose, for a simple function that is already very verbose to begin with, given how little the function does.

I find 9 times out of 10, the source location of the panic (main.rs:123) is enough for debugging, and the .expect() text is redundant. I would never advocate .unwrap() for production services where other people may have to debug the code years after you write it, but there are many, many other use cases for Rust.

If we truly want to get rid of unwrap() in most cases, and not have the language be a bear* to use, then it needs a tactic language or something for proving invariants like that at compile time.

Past that, we're going to have code that calls unwrap(), unless we want what should be simple to consist mostly of pattern matching boilerplate (and functions returning Result<T,...> when they could just be T).

* - Of course, now you have to deal with a tactic language / dependent types, and those could arguably be called a bear in and of themselves ;)

We might not be able to always reason about function totality, but perhaps sometimes we can. Isn't that what `std::convert::Infallible` is trying to do? So you get

   fn try_from(value: U) -> Result<Self, Infallible>

In which case you could potentially avoid the need for an unwrap.

Could you give a more complete example? I see the type signature for the function you're proposing, but I still don't understand what is supposed to replace .unwrap() on the inside of the function.

The "fix" would be to return a Result. Which is a sum of an error and the type you want to return.

But again, the function cannot fail. It could return a Result<Vec2, Infallible>, I guess, but then you're just pushing the unwrap to caller without any need to.

That's the entire point of the OP. That it can't fail so you might as well call unwrap.

You can't return an Infallible, though, because it has no variants. You still need to do something at the point of unwrap().

You'd pair it with something like this https://docs.rs/unwrap-infallible/

I don't see how that would work.

    d[0..4].try_into()

The type of the result is something like:

    Result<[u8; 4], TryFromSliceError>

How do I convert that into

    Result<[u8; 4], Infallible>

As far as I can tell, Infallible is there because you're implementing a trait which returns an error, but you don't have an error to return at all.

In jacobr1's comment we already have a way to get a Result<_, Infallible>. But converting a slice to an array returns a real error type, so my comment wouldn't apply.

For your case just stick with `.try_into().unwrap()`. It's the easiest way. Unless of course someone on crates.io made a fancy crate with const generics.

I couldn't agree more. If course it would be nice of we could prove everything. It would even nicer if we would have a compiler that is smart enough. But it's just not practical for a lot of cases.