为何无法用take_while构造的视图迭代器初始化std::vector？

我在尝试使用std::views库实现幂集函数时遇到了如下问题：

auto set = sv::repeat(0) 
    | sv::take_while([&mask](...) { return mask > 0; })
    | sv::transform([s, &mask, idx = 0](...) mutable { 
        return idx = std::countr_zero(mask & ~(mask - 1)), mask &= mask - 1, s[idx]; });
auto vec = std::vector(set.begin(), set.end());
           ^__________ ^______________________
"*cannot deduce types*"   "*no constructor found*" <- 这是冗长诊断信息的粗略翻译

我的问题是：为什么这段代码无法运行？通常我可以用这类视图正常构造vector，且在函数后续代码中也能成功。

我用无捕获且const的lambda做了相同测试：

auto arr = std::array {1, 2, 3, 3, 4, 5, 6, 1, 2, 3};
auto arr_view = arr | std::views::take_while([](int i) { return i < 4; });
auto vec = std::vector(arr_view.begin(), arr_view.end());

得到了完全相同的错误信息。

更奇怪的是，我尝试用std::ranges::move实现相同功能却成功了！以下代码编译运行均正常（无论视图是右值还是存储在变量中）：

auto arr_view = arr | std::views::take_while([](int i) { return i < 4; });
auto vec = std::vector<int>{};
std::ranges::move(arr_view, std::back_inserter(vec));

起初我以为是因为arr_view不是sized range，但同样非sized range的std::views::filter却可以用迭代方式构造vector。

有人能解释这一现象的原因吗？是因为我使用了（不稳定的）现代特性吗？

核心问题出在**std::views::take_while返回的迭代器不满足LegacyInputIterator要求**，而std::vector的范围构造函数要求传入的迭代器必须是Legacy迭代器（C++20之前的迭代器概念），或者满足std::input_iterator但同时支持std::iterator_traits的完整推导。

具体细节： #

• std::views::take_while的迭代器是单遍迭代器（single-pass iterator），且不提供difference_type的公开typedef，也不支持std::iterator_traits所需的全部关联类型。而std::vector的范围构造函数（template<class InputIterator> vector(InputIterator first, InputIterator last);）依赖于这些关联类型来推导元素类型和分配内存策略。
• 对比std::views::filter：它的迭代器虽然也是单遍，但保留了底层迭代器的difference_type等关联类型，因此能被std::vector的构造函数正确推导。
• std::ranges::move是基于C++20的范围概念设计的，它直接使用std::input_range的要求，不需要依赖Legacy迭代器的iterator_traits，所以能正确处理take_while视图的迭代器。

解决方法： #

• 显式指定std::vector的元素类型，让编译器跳过迭代器关联类型的推导：

  auto vec = std::vector<int>(arr_view.begin(), arr_view.end());
  

• 使用std::ranges::to（C++23特性）直接将视图转换为容器：

  auto vec = arr_view | std::ranges::to<std::vector>();
  

内容的提问来源于stack exchange，提问作者SHIPWECK