[libcxx-commits] [PATCH] D101948: [libc++] Future-proof std::copy for ranges

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a subscriber: rarutyun.
ldionne added a comment.

I am putting this up as a strawman because we will need to go through all of the algorithms and do something similar at some point (before we implement the `ranges::` algorithms).

Basically, we could apply a similar change to all algorithms that require it so that we're ready to implement the `ranges::` version when the time comes. Here's how we would implement `ranges::copy`:

  template<std::input_iterator I, std::sentinel_for<I> S, std::weakly_incrementable O>
    requires std::indirectly_copyable<I, O>
  constexpr ranges::copy_result<I, O> copy( I first, S last, O result ) {
    auto [r1, r2] = _VSTD::__copy(first, last, result);
    return {r1, r2};
  }
  
  template< ranges::input_range R, std::weakly_incrementable O >
    requires std::indirectly_copyable<ranges::iterator_t<R>, O>
  constexpr ranges::copy_result<ranges::borrowed_iterator_t<R>, O> copy(R&& r, O result) {
    return ranges::copy(ranges::begin(r), ranges::end(r), result);
  }

This avoid duplicating any of the actual code in the copy algorithm. That doesn't represent *that much* for `std::copy`, but for other algorithms it'll be more significant, so we want to have a mechanical way of doing it. For algorithms that take a projection, we can implement the internal algorithm taking a projection and simply pass an identity function to implement the regular `std::` algorithm. There are still some issues to think about with this approach, notably that we're copying/moving iterators around a lot more than we used to, which may or may not be a problem depending on whether iterators are cheap to copy.



================
Comment at: libcxx/include/__algorithm/unwrap_iter.h:88
+std::pair<_OrigIter1, _OrigIter2>
+__rewrap_iters(std::pair<_OrigIter1, _OrigIter2> __its,
+               std::pair<_UnwrappedIter1, _UnwrappedIter2> __results)
----------------
This is pretty terrible, and we'll need to introduce one for algorithms that return triples.

I think we should probably write our own little `in_out_result` and `in_in_out_result` pre-C++20 to avoid depending on `pair` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101948