I noticed that C++23's zip_view
has the following constraints:
template<input_range... Views>
requires (view<Views> && ...) && (sizeof...(Views) > 0)
class zip_view;
which implies that zip_view
can only zip input ranges.
I'm wonder why it excludes output_range
, since supporting output_range
can be useful in my opinion. For example, I can zip a bunch of output_range
s for simultaneous writing, a scenario like:
/* zipped input_range */
auto zip_in = views::zip(views::iota(0, 3),
views::iota(3, 6),
views::iota(6, 9));
std::vector<int> v1, v2, v3;
auto make_insert_range = [](auto inserter) {
return ranges::subrange(inserter, std::unreachable_sentinel);
};
/* zipped output_range */
auto zip_out = views::zip(make_insert_range(std::back_inserter(v1)),
make_insert_range(std::back_inserter(v2)),
make_insert_range(std::back_inserter(v3)));
/* copy */
ranges::copy(zip_in, zip_out.begin());
std::println("v1: {}", v1); // v1: [0, 1, 2]
std::println("v2: {}", v2); // v2: [3, 4, 5]
std::println("v3: {}", v3); // v3: [6, 7, 8]
Although zip_out
is currently rejected by the compiler because the constraints are not satisfied.
I believe it is technically feasible to do so. Although this may bring up some thorny issues, such as if a zip input_range
and output_range
at the same time, what category of its iterator would be? I think we can just not provide iterator_concept
and let zip_view
be an input_
range
.
Since I did not find any discussion about supporting output_range
in the original paper P2321 and range/v3, I want to know why zip_view
does not support output range from the first place? Is this an unreasonable option?