[libcxx-commits] [libcxx] [libc++] Merge the implementations of ranges::copy_n and std::copy_n (PR #157444)

[Louis Dionne via libcxx-commits]

================
@@ -13,48 +13,51 @@
 #include <__config>
 #include <__iterator/iterator_traits.h>
 #include <__type_traits/enable_if.h>
-#include <__utility/convert_to_integral.h>
+#include <__utility/move.h>
+#include <__utility/pair.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
+_LIBCPP_PUSH_MACROS
+#include <__undef_macros>
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-template <class _InputIterator,
-          class _Size,
-          class _OutputIterator,
-          __enable_if_t<__has_input_iterator_category<_InputIterator>::value &&
-                            !__has_random_access_iterator_category<_InputIterator>::value,
-                        int> = 0>
-inline _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _OutputIterator
-copy_n(_InputIterator __first, _Size __orig_n, _OutputIterator __result) {
-  typedef decltype(std::__convert_to_integral(__orig_n)) _IntegralSize;
-  _IntegralSize __n = __orig_n;
-  if (__n > 0) {
----------------
ldionne wrote:

If we want to do this refactoring as well, I think we'll need to figure out why we wrote `copy_n` that way in the first place. The difference is that when `n == 1`, we don't increment the iterator in this old version. That could make a difference for input iterators since incrementing them can consume.

Here as well, I'd suggest dropping this refactoring to make progress on the patch, otherwise we'll need to do more digging to understand where that comes from.

https://github.com/llvm/llvm-project/pull/157444