14
#include <vector>
#include <iostream>
#include <range/v3/all.hpp>

int main()
{
    auto coll = std::vector{ 1, 2, 3 };

    ranges::copy(
        coll,
        ranges::ostream_iterator<int>{  std::cout, ", " }
    ); // ok

    ranges::copy(
        coll, 
        std::ostream_iterator<int>{ std::cout, ", " }
    ); // error 
}

The issue is shown in the code above. I use ranges-v3-0.3.7.

To me, the generic algorithm copy shouldn't care about the destination iterator type as long as it meets the requirements of output iterator.

If so, why aren't ranges' algorithms compatible with std's iterators?

Barry
  • 286,269
  • 29
  • 621
  • 977
xmllmx
  • 39,765
  • 26
  • 162
  • 323
  • 1
    Mainly because the ranges support is experimental and not yet standard, so the `std::ostream_iterator` is designed without any support of ranges. The point is demonstrating feasibility of formally introducing such support to a future standard, not locking down a complete specification.Presumably, if ranges is introduced into a future version of the standard, the specification for `ranges::ostream_iterator` will become part of the specification for `std::ostream_iterator`, and `ranges::copy()` will become part of the specification of `std::copy()`, and any incompatibilities will be addressed. – Peter Sep 21 '18 at 02:13
  • 2
    Peter's answer is not quite accurate. It was intentional that `ranges::copy` requires its output iterator be default constructible. And `ranges::copy` will stay `ranges::copy` (`std::ranges::copy`, to be precise) and not be merged with `std::copy`. See Barry's answer below for the low down. – Eric Niebler Sep 21 '18 at 20:11
  • 1
    @EricNiebler: Does `ranges::copy` need to default-construct its output iterator? (Why?) If not, this seems like a needless incompatibility... – Nemo Jun 26 '19 at 21:34
  • Did you try with C++20, https://en.cppreference.com/w/cpp/iterator/ostream_iterator/ostream_iterator says that `std::ostream_iterator` is default constructible, which means from the discussions, that it would work. – alfC Jun 07 '21 at 20:22
  • @Nemo, I have this feeling that ranges always asks for more than what it needs. I also ask myself, why copy would need default construction of iterator?. Maybe it means that I am not thinking right about the problem. Maybe is a blanket requirement that iterators are proper value types, therefore default-constructible in particular. But it always seem that there is a weaker concept lurking around for any specific algorithm. I once did an empirical survey of algorithms that syntactically needed default construction: I could find only 2 in STL and they seem to be gratuitous in the implementation – alfC Jun 07 '21 at 20:28

1 Answers1

24

To me, the generic algorithm copy shouldn't care about the destination iterator type as long as it meets the requirements of output iterator.

This is correct. It's not that ranges::copy somehow recognizes ranges::ostream_iterator and not std::ostream_iterator. It's that Ranges has a refined concept for what an OutputIterator† is, such that ranges::ostream_iterator does model OutputIterator but std::ostream_iterator does not.

Specifically, ranges::copy() requires WeaklyIncrementable<O> which refines SemiRegular<O> which requires DefaultConstructible. ranges::ostream_iterator is default constructible, but std::ostream_iterator is not.

Hence the failure.

In P0896, the range-based copy() algorithm does require WeaklyIncrementable (and thus DefaultConstructible) for its output iterator - but addresses this mismatch by also adding a default constructor to std::ostream_iterator (see page 70).

As an update to this, P2325R3 was just adopted retroactively for C++20, which reverts this change. std::ostream_iterator will no longer be default constructible and the weakly_incrementable concept will no longer require default constructibility (among other changes).

† Note that the range-v3/Ranges TS/Ranges Proposal concept OutputIterator is separate from the standard library's existing concept of OutputIterator. std::ostream_iterator does not model the former but it does model the latter - so using std::copy with a std::ostream_iterator today is perfectly fine. And post-P0896, using ranges::copy with a std::ostream_iterator will also be fine - because of the proposed changes to std::ostream_iterator.

Barry
  • 286,269
  • 29
  • 621
  • 977