lebedev.ri added a comment. In https://reviews.llvm.org/D45163#1054925, @Quuxplusone wrote:
> > I think it wouldn't be unreasonable to ask standard library maintainers to > > add `[[nodiscard]]` to `std::move` > > +1. Also `std::forward`, for sure. Basically any metaprogramming function > that is statically known to return a reference to its argument. > This knowledge is already in the brains of library vendors; they ought to > just write it down in the form of `[[nodiscard]]` annotations. This PR smells > like Clang is trying to "cut out the middleman" and just make up its own > proprietary list of metaprogramming functions that are statically known to > return references to arguments, which is not the most effective or > futureproof way to go about it. Let the library vendors deal with it, please, > says me. A few updates: - `std::move()` *should* be a part of the next paper about `[[nodiscard]]`. Yay! - https://reviews.llvm.org/D45179 *should* make those attributes usable in pre-C++17 code. For people using libc++. But, some points still remain: - `std::move()` is not `[[nodiscard]]` yet - https://reviews.llvm.org/D45179 is not merged yet - Even when either/both things happen, it won't really help those not using libc++ [trunk] / C++17-or-later. That is a *lot* of people. I do agree with @Quuxplusone, we wouldn't want to pull the list of all the `[[nodiscard]]` functions from the standard into clang just because. (we could do that with `clang-tidy`) But maybe `std::move()` is a bit special in this regard... ? Repository: rC Clang https://reviews.llvm.org/D45163 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
