This mirrors what we have done in the classic algorithms
Details
- Reviewers
ldionne Mordante var-const huixie90 - Group Reviewers
Restricted Project - Commits
- rG660b243120bc: [libc++] Add [[nodiscard]] extensions to ranges algorithms
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
LGTM
libcxx/include/__algorithm/ranges_remove_if.h | ||
---|---|---|
68 | not an issue, but I think we can make use of the optional nodiscard string literal to suggest the user to use erase-remove (same of erase-unique) |
FWIW I got positive feedback from some folks on our nodiscard extensions. I resisted them for a while but I now definitely think they're an improvement.
libcxx/test/libcxx/diagnostics/ranges.nodiscard.compile.pass.cpp | ||
---|---|---|
1 | Filename ranges.nodiscard_extensions.compile.pass.cpp maybe? Not as cute but it explains better what it's about. | |
12–14 | I don't think we should try to guard this test against potential future changes in Clang like that. Clang should never implement ranges algorithms as builtins, that sounds like a weird thing to do. | |
libcxx/test/libcxx/diagnostics/ranges.nodiscard.verify.cpp | ||
9–10 | This is an incorrect copy-paste. | |
12–14 | Same comment, let's remove. |
libcxx/include/__algorithm/ranges_remove_if.h | ||
---|---|---|
68 | I'm not sure what you mean exactly. Either way this should probably be it's own PR, in case you feel like it. |
not an issue, but I think we can make use of the optional nodiscard string literal to suggest the user to use erase-remove (same of erase-unique)