修改std::filter_view迭代器元素致UB：为何需维持谓词真值？

Your observed behavior is explicitly undefined behavior (UB) per the C++ standard. When modifying elements in a std::filter_view such that they no longer satisfy the predicate, subsequent iteration results are not guaranteed. The iterator caching in filter_view's implementation is an optimization that relies on a key invariant: once an element passes the predicate, it remains valid for the view's lifetime. Breaking this invariant leads to inconsistent results, as seen in your example where the second iteration only modifies one element instead of two.

Is the requirement counterintuitive? #

At first glance, it might feel restrictive—modifying range elements is a routine operation. But this constraint stems from the core design goals of C++20 ranges: lazy evaluation, zero overhead, and simplicity. Filter views don't store element copies; they act as thin wrappers over the underlying range, applying the predicate on demand. The caching behavior is critical for efficiency—without it, each iterator increment would require re-scanning from the current position (or even the start of the range), leading to O(n²) time complexity in worst-case scenarios.

What compromises would be needed to relax this restriction? #

If the standard allowed modifying elements in ways that break the predicate, several trade-offs would be unavoidable:

• Abandon iterator caching: Every iterator increment would re-check the predicate from the current position. This eliminates UB but makes filter view iteration drastically slower, especially for large ranges where most elements are filtered out.

• Invalidate iterators on modification: Any change that could break the predicate would invalidate all existing iterators to the filter view. This aligns with container iterator semantics but undermines the stability expected of range views, which are meant to provide stable iterators as long as the underlying range remains unmodified.

• Track element modifications: Maintain a separate data structure to track modified elements, so iterators can re-verify their predicate status. This adds memory overhead and runtime complexity, violating the "zero-overhead" promise of range views and complicating implementation for edge cases like concurrent access.

Why weren't these compromises adopted? #

The C++ standard committee prioritized efficiency and simplicity over eliminating this constraint. Range views are designed to be drop-in replacements for hand-written loops with no performance penalty. The predicate preservation requirement is a small user-facing constraint that enables the view to maintain optimal performance and a clean, lightweight implementation.

This pattern isn't unique to filter_view—other views like std::sorted_view have similar invariants (requiring the underlying range to remain sorted). It's a common trade-off where users accept a small constraint in exchange for the performance and simplicity of the view abstraction.

Content of the question originates from Stack Exchange, asked by gonidelis