read is still O(N), of course, but iterators are otherwise smaller and cheaper. Drive-by: merge pairs of end() and end() const overloads replacing concept overloading with if constexpr dispatch.

In Godbolt, I have imported zip.hpp (by manualling copy and pasting)

https://godbolt.org/z/vrcaP6jbj

Not compiling in clang :

• error: missing 'typename' prior to dependent type name 'detail::tuple_or_pair_impl<Ts...>::type' using tuple_or_pair = detail::tuple_or_pair_impl<Ts...>::type;

This may be related to another issue I have had using zip with std::view and it failing to compile (in MSCV) because of some indecipherable templating error

transform_maybe currently doesn't cache begin, and it could be that the begin is anywhere in the underlying range, so begin on our transform_maybe_view is not amortized constant time. It should cache begin.

This should compile:

auto cycle_then_enumerate = tl::views::cycle | tl::views::enumerate;
for (auto&& [i,e] : vec | cycle_then_enumerate) {
  //...
}

This should also compile:

template <std::integral N>
auto drop_then_enumerate(N n) {
  return tl::make_pipeable(std::drop(n)) | tl::enumerate;
}

cycle_view currently requires bidirectional ranges to be common because it assigns std::ranges::end(base_) to current_ when it cycles from begin to end. Non-common, sized, bidirectional ranges should be supported.

Range-v3 supports non-common, non-sized bidirectional ranges by --begin(my_cycle_view) being O(n) unless end has been cached. I don't think we should do that.

In the unit test below, a compilation error occurs.

TEST_CASE("std::ranges::iota_view") {
    for (auto&& [i, j] : (std::views::iota(0) | tl::views::enumerate | std::views::take(10))) {
        REQUIRE(i == j);
    }
}

Error message:

error C2678: binary '|': no operator found which takes a left-hand operand of type 'tl::enumerate_view<std::ranges::iota_view<_Ty,std::unreachable_sentinel_t>>' (or there is no acceptable conversion) with [ _Ty=int ]

https://github.com/TartanLlama/ranges/blob/main/include/tl/to.hpp#L99

Hi Sy, I'm trying to compile your code and have run up against this line. Is typename required before ContainerType's default type?

template<int X>
struct foo;

template<int X, typename Y = foo<X>::type>
struct bar;

This is the same thing. It compiles with gcc and msvc but breaks with clang. Is this a context in which typename is relaxed for C++20, or is it a bug? Just asking so I can make the changes in my compiler if needed.

http://eel.is/c++draft/temp.res#general-4.2.5

I think this is a relaxed typename context, but it surprises me that clang trunk doesn't get this basic scenario right.

Hi, Currenly the test programs include stuff before they include the header of the view they are testing I.E.

#include <catch2/catch.hpp>
#include <vector>
#include <iostream>
#include "tl/chunk.hpp"
#include "tl/to.hpp"
#include "tl/enumerate.hpp"

in chunk.cpp. It would good to include the view you are testing first to make sure the header for that vierw is idempotent I.E

#include "tl/chunk.hpp"  // Make sure this does not depend on things it does not include
#include "tl/to.hpp"
#include "tl/enumerate.hpp"
#include <catch2/catch.hpp>
#include <vector>
#include <iostream>

Let me know if you agree and I will create a pull request

The can_reference concept was defined in both adjacent_transform and zip_transform.h. This factors this concept out and puts it in common.hpp

Also added tl.h to include everything to check for similar, hopefully one day this will be a single module!

Note I'm pretty new with ranges and concepts so I may be doing something dumb. This is with VS 17.1 Preview 2. I have used zip_view for a few things without problem. Removing the const in the vector and span makes the error go away.

`void foo( ) { std::vector const ints { 0, 1, 2 }; std::span sp { ints };

auto v { tl::zip_view( sp, ints ) };
auto p { []( auto const& x ) -> bool { return true; } };

// This does not compile with
// 1>C:\Users\foo\source\repos\TL\ranges\src\ranges.cpp(18,18): error C2672: 'operator __surrogate_func': no matching overloaded function found
// 1>C:\Users\foo\source\repos\TL\ranges\src\ranges.cpp(18,31): error C7602: 'std::ranges::_Any_of_fn::operator ()': the associated constraints are not satisfied
std::ranges::any_of( v, p )

};`

zip_view.zip

chunk_by_key_view currently supports forward ranges, because it's much easier. It can be made to support input ranges by having inner and outer cursors which communicate.