Why does `zip_view` not support `output_range`?

Question

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

Answer 1

This is certainly possible, though uncommon, and has limited applicability. Even in your example, strictly speaking, we don't need a zip of views; something like a zip of iterators is sufficient. Other use cases, as mentioned by Barry, merely include iota, fill, and generate for now, where we should be able to use some tuple-like objects to fill the underlying output ranges, respectively. Even if we relaxed the constraints of zip, allowing output_ranges to be zipped, we might not want to allow zipping a mix of input_ranges and output_ranges, which would result in adding more constraints. Therefore, it's just not worth the trouble.