[libc++] Mark string functions as [[nodiscard]]

[philnik777]

This applies [[nodiscard]] according to our coding guidelines to basic_string.

[github-actions]

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:

git-clang-format --diff origin/main HEAD --extensions ,cpp -- libcxx/include/string libcxx/test/libcxx/diagnostics/string.nodiscard.verify.cpp libcxx/test/libcxx/strings/basic.string/nonnull.verify.cpp --diff_from_common_commit

⚠️
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing origin/main to the base branch/commit you want to compare against.
⚠️

View the diff from clang-format here.

diff --git a/libcxx/include/string b/libcxx/include/string
index cf2208fb2..79da203cf 100644
--- a/libcxx/include/string
+++ b/libcxx/include/string
@@ -1269,7 +1269,8 @@ public:
   [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 reverse_iterator rbegin() _NOEXCEPT {
     return reverse_iterator(end());
   }
-  [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 const_reverse_iterator rbegin() const _NOEXCEPT {
+  [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 const_reverse_iterator
+  rbegin() const _NOEXCEPT {
     return const_reverse_iterator(end());
   }
   [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 reverse_iterator rend() _NOEXCEPT {
@@ -1772,8 +1773,8 @@ public:
   _LIBCPP_CONSTEXPR_SINCE_CXX20 size_type copy(value_type* __s, size_type __n, size_type __pos = 0) const;
 
 #  if _LIBCPP_STD_VER <= 20
-  [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string
-  substr(size_type __pos = 0, size_type __n = npos) const {
+  [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI
+  _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string substr(size_type __pos = 0, size_type __n = npos) const {
     return basic_string(*this, __pos, __n);
   }
 #  else
@@ -2100,7 +2101,8 @@ public:
     return !empty() && _Traits::eq(front(), __c);
   }
 
-  [[__nodiscard__]] constexpr _LIBCPP_HIDE_FROM_ABI bool starts_with(const value_type* _LIBCPP_DIAGNOSE_NULLPTR __s) const noexcept {
+  [[__nodiscard__]] constexpr _LIBCPP_HIDE_FROM_ABI bool
+  starts_with(const value_type* _LIBCPP_DIAGNOSE_NULLPTR __s) const noexcept {
     return starts_with(__self_view(__s));
   }
 
@@ -2114,7 +2116,8 @@ public:
     return !empty() && _Traits::eq(back(), __c);
   }
 
-  [[__nodiscard__]] constexpr _LIBCPP_HIDE_FROM_ABI bool ends_with(const value_type* _LIBCPP_DIAGNOSE_NULLPTR __s) const noexcept {
+  [[__nodiscard__]] constexpr _LIBCPP_HIDE_FROM_ABI bool
+  ends_with(const value_type* _LIBCPP_DIAGNOSE_NULLPTR __s) const noexcept {
     return ends_with(__self_view(__s));
   }
 #  endif

[H-G-Hristov]

@philnik777 I have a related off-topic question. The coding guidelines are quite clear about applying [[nodiscard]].
What about applying those at a scale to an already existing code? Was this already discussed and is it desirable? Is there a policy about that?
For example math functions should be marked [[nodiscard]]. I have prepared a PR for the saturation math functions, etc. Should I go ahead with revisiting mine and other older code and adding the attribute?

[philnik777]

@philnik777 I have a related off-topic question. The coding guidelines are quite clear about applying [[nodiscard]]. What about applying those at a scale to an already existing code? Was this already discussed and is it desirable?

The entire reason for having the guideline was that we want to apply [[nodiscard]] throughout the code base. Unlike most coding guidelines this has a direct impact on our QoI, so yeah, it's desirable.

Is there a policy about that? For example math functions should be marked [[nodiscard]].

Some math functions should be marked [[nodiscard]].

I have prepared a PR for the saturation math functions, etc. Should I go ahead with revisiting mine and other older code and adding the attribute?

That would be great.