https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123182
--- Comment #2 from Pavel Šimerda <code at simerda dot eu> --- (In reply to Jonathan Wakely from comment #1) > Modifying the underlying range in a way that changes whether an element > matches the filter predicate results in undefined behaviour, see > [range.filter.iterator]/1 in the C++ standard: > > Modification of the element a filter_view::iterator denotes is > permitted, > but results in undefined behavior if the resulting value does not satisfy > the filter predicate. I see. So the battle has already been lost on the side of the standards. Thank you for clarification and for the references. Good to know that this has already been discussed. > No, the first time you call begin() the view finds the first matching > element and then caches that iterator, so that calling begin() again is fast. Yes. But the main use cases of calling it again (when the data could potentially have changed in the meantime) is a no-go. But as you say, it's not in our power to fix it.
