Avoiding range-v3 footguns (e.g views::filter) [closed]

Question

I would like to share a few "footguns" discovered over my (brief) course of using range-v3

1: Views::filter memory corruption

sourceRange | views::filter(predicate) | ranges::to<...>();

For some reason, this can invoke filter multiple times. Which is dandy when filter is pure and deterministic, but not when it's nondeterministic.

I recently discovered a problematic filter predicated on the current system time, which was liable to shift across multiple invocations on the same element. One invocation would filter it, the next would keep it. The result: an insidious crash, as the ranges::to implementation seemingly filters in two passes in this particular case:

• The first pass: to determine the resultant size of the target converted container. In order to preallocate a buffer

• The second pass: to actually determine elements to fill the preallocated buffer

The insidious part: if the second filtration pass permits more elements through than the first, the preallocated buffer would silently overflow with no checks.

2: Multiple Invocation of views::transform

• See related question here

In some situations (in conjunction with views::filter or views::remove_if that I am aware of), views::transform can potentially be invoked multiple times per element.

Again, this is totally fine if transform is deterministic without side-effects on the source range. But it is distinctly not so if it mutates the source range in a non-idempotent manner. Suppose:

sourceRangeOfA 
  | views::move 
  | views::transform(convertByMoveToB) 
  | views::filter(somePredicate)

Clearly, multiple invocations of transform on the same element can be disastrous.

My Question

I want to love and continue using ranges, I really do. But some of these bugs were tough lessons to learn and particularly painful to troubleshoot. What's particularly hard to swallow here: rewriting the two above examples in an iterative style completely resolves the problems. Which seems backwards: ranges should be safer, not more dangerous.

What I ask is -- what other footguns abound, and what lessons can we draw from this?

• Should all mutations (e.g views::transform) be deterministic and const with respect to elements on which they are applied?
  • This obviously precludes views::move, so we are trading off performance to use range-v3. It doesn't feel like a great tradeoff
  • The alternative is views::cache1. My gripe with this is that it's sometimes not immediately intuitive when potentially needed - especially to range newbies. And if you forget it - disaster looms'
• Otherwise, if I really wanted non-const transforms, what other views do I need to watch for which are dangerous in conjunction (like filter)
• What other view adapter combinations are problematic and lurking footguns?
• Should filter always be pure and deterministic?
• Should filter or any "filtration" style range ever be used with transform?
• Why aren't these footguns captured in the documentation?
• Can std::ranges do better?