You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for (auto &&[a, b, c] :
tl::views::cartesian_product(std::views::iota(0, 3), std::views::iota(0, 3), std::views::iota(0, 3)) |
std::views::transform([](auto val) { return val; }))
std::cout << a << ' ' << b << ' ' << c << '\n';
works fine, but:
for (auto &&[a, b] : tl::views::cartesian_product(std::views::iota(0, 3), std::views::iota(0, 3)) |
std::views::transform([](auto val) { return val; }))
std::cout << a << ' ' << b << '\n';
fails to compile because when cartesian_product only uses 2 ranges, tuple_transform returns a pair instead of a tuple and cartesian_product_view is not using that consistently. The iterator fails to be an input_iterator because it is not indirectly_readable, "common_reference_with<iter_reference_t<_In>&&, iter_value_t<_In>&> &&" fails because iter_reference_t uses a pair and iter_value_t uses a tuple. At least that's what I think is happening; once I eliminated the specialization for pair in tuple_or_pair_impl it works. That's definitely not a fix though, but I don't know where the actual bug lies.
The text was updated successfully, but these errors were encountered:
There is a bug with just 2 ranges:
for (auto &&[a, b, c] :
tl::views::cartesian_product(std::views::iota(0, 3), std::views::iota(0, 3), std::views::iota(0, 3)) |
std::views::transform([](auto val) { return val; }))
std::cout << a << ' ' << b << ' ' << c << '\n';
works fine, but:
for (auto &&[a, b] : tl::views::cartesian_product(std::views::iota(0, 3), std::views::iota(0, 3)) |
std::views::transform([](auto val) { return val; }))
std::cout << a << ' ' << b << '\n';
fails to compile because when cartesian_product only uses 2 ranges, tuple_transform returns a pair instead of a tuple and cartesian_product_view is not using that consistently. The iterator fails to be an input_iterator because it is not indirectly_readable, "common_reference_with<iter_reference_t<_In>&&, iter_value_t<_In>&> &&" fails because iter_reference_t uses a pair and iter_value_t uses a tuple. At least that's what I think is happening; once I eliminated the specialization for pair in tuple_or_pair_impl it works. That's definitely not a fix though, but I don't know where the actual bug lies.
The text was updated successfully, but these errors were encountered: