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