[Question, Suggestion] Would a variadic `zip()` be useful for the library?

[juntuu]

A variadic zip() might make implementing other variadic algorithms easy in terms of existing stl algorithms. It might also be useful on its own.

The function would take variadic number of ranges, and return a range that iterates over all the input ranges, advancing all the input range iterators at each step, and yielding a tuple of values when dereferencing. The zipped range would only iterate until the shortest input range is consumed.

For example:

auto a = std::vector{1, 2, 3, 4};
auto b = std::vector{1, 2};
auto zipped = zip(a, b);
auto it = zipped.begin();

*it == std::tuple{*a.begin(), *b.begin()};
++it;
*it == std::tuple{*(a.begin()+1), *(b.begin() + 1)};
++it;
(it != zipped.end()) == false; // b only had 2 elements

I played around a bit with the idea and wrote a little poc implementation https://godbolt.org/z/9oGWs9.

Ps. boost seems to have something similar https://www.boost.org/doc/libs/1_75_0/libs/iterator/doc/zip_iterator.html

[Sebanisu]

So would this be like a range adapter/view? So would this be like a version of what we're getting in c++23? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2214r0.html#the-zip-family

[juntuu]

Something like that, yes. I wasn't aware of the plans for it in c++23, thanks for pointing that out

It could also be made with iterator pairs like zip(a.begin(), a.end(), b.begin(), b.end(), c.begin(), c.end(), ...) or less safe zip(a.begin(), a.end(), b.begin(), c.begin(), ...), but using ranges might be nicer.

[codereport]

I think in general our policy should be to add algorithms when we need them. So if this comes up in the future we can add it.

[juntuu]

I totally agree, algorithm with no use is essentially dead code.

The main reason I started this discussion, was because I was thinking whether or not zip() would be beneficial for implementing the other variadiac algorithms.