blob: 208188ce971a5827930587d7bbe1de91a6a2b95f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
### What it does
As the counterpart to `or_fun_call`, this lint looks for unnecessary
lazily evaluated closures on `Option` and `Result`.
This lint suggests changing the following functions, when eager evaluation results in
simpler code:
- `unwrap_or_else` to `unwrap_or`
- `and_then` to `and`
- `or_else` to `or`
- `get_or_insert_with` to `get_or_insert`
- `ok_or_else` to `ok_or`
### Why is this bad?
Using eager evaluation is shorter and simpler in some cases.
### Known problems
It is possible, but not recommended for `Deref` and `Index` to have
side effects. Eagerly evaluating them can change the semantics of the program.
### Example
```
// example code where clippy issues a warning
let opt: Option<u32> = None;
opt.unwrap_or_else(|| 42);
```
Use instead:
```
let opt: Option<u32> = None;
opt.unwrap_or(42);
```
|
