[libcxx-commits] [PATCH] D65721: Make rotate a constexpr

[Zoe Carver via Phabricator via libcxx-commits]

zoecarver marked 2 inline comments as done.
zoecarver added inline comments.


================
Comment at: libcxx/include/algorithm:2308
 template <class _ForwardIterator>
-_ForwardIterator
+_LIBCPP_CONSTEXPR_AFTER_CXX17 _ForwardIterator
 __rotate_left(_ForwardIterator __first, _ForwardIterator __last)
----------------
ldionne wrote:
> This function can be made constexpr in all standard modes that support generalized constexpr (so C++14 and above).
> 
> That holds for all helper functions below.
Was `std::rotate` updated as a paper or an issue? Or have we decided to extend constexpr support back to C++14 independent of the standard? 


================
Comment at: libcxx/test/std/algorithms/alg.modifying.operations/alg.rotate/rotate.pass.cpp:458
+#if TEST_STD_VER > 17
+    static_assert(test_constexr<forward_iterator<int*> >());
+    static_assert(test_constexr<bidirectional_iterator<int*> >());
----------------
ldionne wrote:
> It would be nice if we could run all the same tests for constexpr and non-constexpr. It's not clear to me why we can't just run `test<....>` in a constexpr context. As for `test1`, it allocates memory but it might be possible to change the test to avoid that?
> 
> Generally speaking, I'd like for us to develop a fairly mechanical way of testing things in a constexpr context, since we're going to have to do that for almost all of `<algorithm>`. I think it's important to have the same test coverage for constexpr and non-constexpr (whenever it makes sense, of course).
I agree. What if we decided that we test constexpr by adding `return true` to the end of the test function and modifying the function to be a constexpr that returns a bool. This should work for almost all `<algorithm>` tests. 


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65721/new/

https://reviews.llvm.org/D65721