4 ms·

> It’s crazy how Rust just gets rid of this whole class of bugs with option and result types (and sum types in general). As a Rust security consultant, many bu

• rowanG077 5y ago
  I disagree. A nil error in Go is most likely a dev forgetting a check. An unwrap() is a dev explicitly saying this should always contain a value. In fact fixing unwrap is as easy as search for unwrap in your codebase and factoring them all out.
  • vaylian 5y ago
    > An unwrap() is a dev explicitly saying this should always contain a value Isn't expect() supposed to cover that case?
    • rowanG077 5y ago
      No it's the opposite. Unwrap() means the dev said this will never not be set. Expect() is saying if this value is not available exit the program with this user facing error message.
    • ModernMech 5y ago
      expect() is like unwrap() but you can give a message as an argument.
• mathw 5y ago
  It is a shame there are so many Rust examples out there with unwrap() all over them, because it's really not something I would want to see in production code. expect() with a message if you know that the only reason this fails is because something else messed up that should have prevented the call in the first place, sure. unwrap()? No thanks. That's why we have the ? operator now.
  • da39a3ee 5y ago
    Agreed, except I don't think people should use expect() since its name is a mistake made early on in Rust: people use it to write expect("something bad we don't expect") unwrap_or_else(|| panic!(...)) is clear and doesn't suffer from the naming mistake.