Why aren't ranges' algorithms compatible with std's iterators?

Question

#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?

Aileen

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. – Cotton

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. – Poff

@EricNiebler: Does ranges::copy need to default-construct its output iterator? (Why?) If not, this seems like a needless incompatibility... – Mcculloch

Did you try with C++20, en.cppreference.com/w/cpp/iterator/ostream_iterator/… says that std::ostream_iterator is default constructible, which means from the discussions, that it would work. – Sibship

@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 – Sibship

Answer 1

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.

Immure

Yes, much better, and much less scary :) – Mieshamiett

Hmm... how come ranges::ostream_iterator is default-constructible? Shouldn't it require an ostream? – Bosnia

@Bosnia It doesn't need to - you can always assign it later. – Immure

@Immure : I thought separating "official" construction from "effective"construction was kind of a no-no these days. Can you even do anything with a ranges::ostream_iterator {}? – Bosnia

@Bosnia No, you can't really. – Immure

@Barry: Weird; I just asked about this in a separate question. – Bosnia

@einpoklum, std::ostream_iterator is default constructible in C++20, en.cppreference.com/w/cpp/iterator/ostream_iterator/…. – Sibship

@Sibship Not as of today. – Immure