rust - 为什么我应该更喜欢 `Option::ok_or_else` 而不是 `Option::ok_or` ？

Question

我刚刚在拉取请求中看到以下更改:

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

我知道的唯一区别是:

1. 在 ok_or 中，我们已经通过 Error::new 创建了 Error 并将其传递给适配器。
2. 在 ok_or_else 中，我们传递了一个闭包，它将产生这样一个值，但如果 Option 中有 Some 数据，则可能不会调用它>.

我错过了什么吗？

Answer 1

使用 ok_or_else 或 any ..._or_else 方法的主要原因是避免在不需要时执行函数。对于 Option::ok_or_else 或 Option::unwrap_or_else，当 Option 为 Some 时，无需运行额外代码。这可以使代码更快，具体取决于错误情况下发生的情况

在此示例中，Error::new 可能执行分配，但它也可以写入标准输出、发出网络请求或任何 Rust 代码片段可以执行的操作；从外面很难说。将此类代码放在闭包中通常更安全，因此在成功案例发生时您不必担心无关的副作用。

Clippy 也为您检查了这个:

fn main() {
    let foo = None;
    foo.unwrap_or("hello".to_string());
}

warning: use of `unwrap_or` followed by a function call
 --> src/main.rs:3:9
  |
3 |     foo.unwrap_or("hello".to_string());
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `unwrap_or_else(|| "hello".to_string())`
  |
  = note: `#[warn(clippy::or_fun_call)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#or_fun_call