Using unwrap() in Rust is okay

Re:Using unwrap() in Rust is okay by deathanatos on Monday August 08, 2022 @09:31PM (#32393203)

Guilty as charged, and honestly, I wish I had a good mechanism/function call to separate "I'm just being lazy here, this is a TODO" from "actually, this should never happen.

  .map_err(|_| unimplemented!()).unwrap()

or something. (I hope you get the gist of that, as I'm 99% sure that code doesn't compile. Error(E) -> !, Ok(T) -> T)

[ Parent | on HN ]

Re:Using unwrap() in Rust is okay by dureuill on Wednesday August 10, 2022 @04:52AM (#32409357)

You could go:

    result.unwrap_or_else(|| todo !())

(unimplemented! is for missing functionality in a given version, todo! is for missing functionality during development)

But using unwrap for these kinds of TODO is ok, code review won't let unjustified unwraps to pass

[ Parent | on HN ]

Re:Using unwrap() in Rust is okay by burntsushi on Monday August 08, 2022 @10:00PM (#32393450)

Just write 'expect("FIXME")' or similar. :-)

[ Parent | on HN ]

Re:Using unwrap() in Rust is okay by deathanatos on Tuesday August 09, 2022 @02:30AM (#32394843)

I've thought about this, it just requires some effort, particular if you want the result to be grep-able. (And, in >1 person groups, then it requires coordination, although perhaps also all of those should be remove prior to committing…)

[ Parent | on HN ]

Re:Using unwrap() in Rust is okay by burntsushi on Tuesday August 09, 2022 @09:07AM (#32397267)

I think anything you do here is going to require some kind of effort.

Personally, I think it would be better to stop thinking about 'unwrap()' as its own special thing. 'unwrap()' is just a common manifestation of something much more fundamental: runtime invariants. Think about those.

[ Parent | on HN ]