std::ranges::fill要求范围迭代器可写，仅支持绑定到可修改容器的视图（如views::take、views::drop、subrange），不支持filter、transform等只读视图，否则编译失败。
std::ranges::fill 要求迭代器必须可写，视图需支持 mutable 迭代
直接对大多数 std::views（如 std::views::filter、std::views::transform）调用 std::ranges::fill 会编译失败，因为这些视图产生的迭代器是只读的（const_iterator 类型），而 std::ranges::fill 需要可解引用并赋值的迭代器。错误典型提示：assignment of read-only location 或 no match for operator=。
只有底层容器元素本身可修改、且视图未施加只读约束时，才能填充。例如：
-
std::views::take和std::views::drop—— 若源容器可修改，它们的迭代器通常可写 -
std::views::subrange（包装原生指针或容器迭代器）—— 只要底层支持写入 -
std::span或std::vector直接转成视图 —— 安全可用
正确用法：先确认视图是否绑定到可修改左值容器
关键不是“视图能不能 fill”，而是“视图所指的内存是否实际可写”。常见安全场景：
std::vector<int> vec = {1, 2, 3, 4, 5};
auto v = std::views::take(vec, 3); // 绑定到 vec，vec 元素可写
std::ranges::fill(v, 99); // ✅ 成功：vec[0..2] 变为 {99,99,99}
但下面会失败：
立即学习“C++免费学习笔记（深入）”；
auto v2 = std::views::filter(vec, [](int x) { return x % 2 == 0; });
std::ranges::fill(v2, 0); // ❌ 编译错误：filter_view::iterator 不支持赋值
原因：filter 视图不保证连续存储，也无法反向映射到原容器可写位置，标准库禁止这种填充语义。
替代方案：对 filter / transform 等只读视图，必须手动定位并修改原容器
如果真想把满足条件的元素设为某值，不能靠 std::ranges::fill，得用 std::ranges::for_each 或带索引的遍历，作用于原容器：
- 用
std::ranges::for_each+ lambda 修改原容器元素：std::ranges::for_each(vec, [](int& x) { if (x % 2 == 0) x = 0; }); - 若需复用 filter 逻辑，可先收集满足条件的迭代器（如
std::vector<int*>），再逐个赋值 - 避免用
std::views::iota或std::views::repeat直接填 —— 它们生成的是右值或常量序列，无法被fill修改
性能与陷阱：fill 对视图无额外开销，但误用会导致静默逻辑错误
std::ranges::fill 本身只是循环赋值，没有视图特化开销；问题出在语义误解。容易踩的坑包括：
- 对
std::views::common包装后的视图调用 fill —— 若内部是只读视图，common 不改变可写性 - 用 auto 推导视图类型后传给 fill，编译器可能接受但运行时行为不符合预期（比如某些自定义视图未正确定义 reference 类型）
- 在函数参数中接收
std::ranges::range auto&&并尝试 fill —— 若传入的是临时视图（如vec | std::views::take(3)），即使能编译，也可能修改的是临时副本，原容器不变
最稳妥的做法：始终确保 fill 的范围表达式最终绑定到一个具名、可修改、生命周期足够的容器对象，而不是链式管道中的中间视图。
