[libcxx-commits] [libcxx] [libc++] Document guidelines for applying [[nodiscard]] (PR #84000)

[Nikolas Klauser via libcxx-commits]

https://github.com/philnik777 updated https://github.com/llvm/llvm-project/pull/84000

>From d3497911654ae3f48abd1e0485a26bf920c8e052 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser <nikolasklauser at berlin.de>
Date: Tue, 5 Mar 2024 13:08:11 +0100
Subject: [PATCH] [libc++][RFC] Document when to apply [[nodiscard]]

---
 libcxx/docs/DesignDocs/NodiscardPolicy.rst | 42 ++++++++++++++++++++++
 libcxx/docs/index.rst                      |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 libcxx/docs/DesignDocs/NodiscardPolicy.rst

diff --git a/libcxx/docs/DesignDocs/NodiscardPolicy.rst b/libcxx/docs/DesignDocs/NodiscardPolicy.rst
new file mode 100644
index 00000000000000..afbb18b0096d73
--- /dev/null
+++ b/libcxx/docs/DesignDocs/NodiscardPolicy.rst
@@ -0,0 +1,42 @@
+===================================================
+Guidelines for applying ``[[nodiscard]]`` in libc++
+===================================================
+
+Libc++ adds ``[[nodiscard]]`` to functions in a lot of places. The standards
+committee has decided to not have a recommended practice where to put them, so
+this document lists where ``[[nodiscard]]`` should be applied in libc++.
+
+When should ``[[nodiscard]]`` be added to functions?
+====================================================
+
+``[[nodiscard]]`` should be applied to functions
+
+- where discarding the return value is most likely a correctness issue.
+  For example a locking constructor in ``unique_lock``.
+
+- where discarding the return value likely points to the user wanting to do
+  something different. For example ``vector::empty()``, which probably should
+  have been ``vector::clear()``.
+
+  This can help spotting bugs easily which otherwise may take a very long time
+  to find.
+
+- which return a constant. For example ``numeric_limits::min()``.
+- which only observe a value. For example ``string::size()``.
+
+  Code that discards values from these kinds of functions is dead code. It can
+  either be removed, or the programmer meant to do something different.
+
+- where discarding the value is most likely a misuse of the function. For
+  example ``find``.
+
+  This protects programmers from assuming too much about how the internals of
+  a function work, making code more robust in the presence of future
+  optimizations.
+
+What should be done when adding ``[[nodiscard]]`` to a function?
+================================================================
+
+Applications of ``[[nodiscard]]`` are code like any other code, so we aim to
+test them. This can be done with a ``.verify.cpp`` test. Many examples are
+available. Just look for tests with the suffix ``.nodiscard.verify.cpp``.
diff --git a/libcxx/docs/index.rst b/libcxx/docs/index.rst
index aa1bd4b83b265b..2a7e47dfe6d88b 100644
--- a/libcxx/docs/index.rst
+++ b/libcxx/docs/index.rst
@@ -189,6 +189,7 @@ Design Documents
    DesignDocs/FeatureTestMacros
    DesignDocs/FileTimeType
    DesignDocs/HeaderRemovalPolicy
+   DesignDocs/NodiscardPolicy
    DesignDocs/NoexceptPolicy
    DesignDocs/PSTLIntegration
    DesignDocs/ThreadingSupportAPI