summaryrefslogtreecommitdiffstats
path: root/src/tools/clippy/src/docs/or_fun_call.txt
diff options
context:
space:
mode:
Diffstat (limited to 'src/tools/clippy/src/docs/or_fun_call.txt')
-rw-r--r--src/tools/clippy/src/docs/or_fun_call.txt27
1 files changed, 27 insertions, 0 deletions
diff --git a/src/tools/clippy/src/docs/or_fun_call.txt b/src/tools/clippy/src/docs/or_fun_call.txt
new file mode 100644
index 000000000..6ce77cc26
--- /dev/null
+++ b/src/tools/clippy/src/docs/or_fun_call.txt
@@ -0,0 +1,27 @@
+### What it does
+Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,
+`.or_insert(foo(..))` etc., and suggests to use `.or_else(|| foo(..))`,
+`.unwrap_or_else(|| foo(..))`, `.unwrap_or_default()` or `.or_default()`
+etc. instead.
+
+### Why is this bad?
+The function will always be called and potentially
+allocate an object acting as the default.
+
+### Known problems
+If the function has side-effects, not calling it will
+change the semantic of the program, but you shouldn't rely on that anyway.
+
+### Example
+```
+foo.unwrap_or(String::new());
+```
+
+Use instead:
+```
+foo.unwrap_or_else(String::new);
+
+// or
+
+foo.unwrap_or_default();
+``` \ No newline at end of file