Why should I prefer `Option::ok_or_else` instead of `Option::ok_or`?

Question

I just saw the following change in a pull request:

- .ok_or(Error::new(ErrorKind::Other, \"Decode error\"));
+ .ok_o         


        

Answer 1

In addition to performance implications, more complex arguments in ok_or might yield unexpected results if one is not careful enough; consider the following case:

fn main() {
    let value: Option = Some(1);

    let result = value.ok_or({ println!("value is not Some!"); 0 }); // actually, it is

    assert_eq!(result, Ok(1)); // this holds, but "value is not Some!" was printed
}

This would have been avoided with ok_or_else (and the same goes for other *_or_else functions), because the closure is not evaluated if the variant is Some.