为什么我应该选择`Option::ok_or_else`而不是`Option::ok_or`呢？
为什么我应该选择`Option::ok_or_else`而不是`Option::ok_or`呢？
提问于 2017-08-07 12:47:26
我刚刚在拉请求中看到了以下变化：
- .ok_or(Error::new(ErrorKind::Other, "Decode error"));
+ .ok_or_else(|| Error::new(ErrorKind::Other, "Decode error"));我知道的唯一不同之处是：
- 在
ok_or中，我们已经通过Error::new创建了Error并将其传递给适配器。 - 在
ok_or_else中，我们传递了一个闭包，它将产生这样的值，但如果Option中有Some数据，则可能不会调用它。
我错过什么了吗？
Stack Overflow用户
回答已采纳
发布于 2017-08-07 12:53:20
使用ok_or_else或任何..._or_else方法的主要原因是避免在不需要时执行函数。在Option::ok_or_else或Option::unwrap_or_else的情况下，当Option是Some时不需要运行额外的代码。这可以使代码更快，这取决于在错误情况下发生了什么。
在本例中，Error::new可能执行分配，但它也可以写入标准输出、发出网络请求或任何锈蚀代码所能做的事情；从外部很难分辨。通常，将这样的代码放在闭包中是比较安全的，因此当成功案例发生时，您不必担心额外的副作用。
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页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/45547293
复制相关文章
相似问题
腾讯云开发者
