std.collection - changing the collection while iterating

[Jonathan M Davis via Digitalmars-d]

On Sunday, 21 June 2015 at 23:58:38 UTC, H. S. Teoh wrote:
> On Sun, Jun 21, 2015 at 04:02:43PM -0700, Andrei Alexandrescu 
> via Digitalmars-d wrote:
>> 3. Allow the removal but throw from the ranges if there's any 
>> attempt to use a range following a remove.
>
> This is also too extreme. If I'm iterating over a linked-list 
> on the 50th element, there is no reason why deleting the first 
> element of the list should cause an exception when I later want 
> to visit the 51st element.

Which is why I would suggest that we consider the issue from the 
perspective of iterator/range invalidation. If the operation that 
you did on the container does not alter the number of elements in 
the range or which elements it refers to, then that range should 
still be considered valid and work exactly as it would have had 
the container operation not taken place. But if it _does_ alter 
the range, then the range should be considered invalidated, and 
it should be a logic error to continue to iterate over that range 
at that point.

That's basically how it's dealt with in C++. It's just that what 
happens when you iterate using an invalidated iterator is 
undefined behavior, and we could choose to throw an Error in that 
case if we wanted to be more user-friendly. That would generally 
result in a slight performance hit, but it would probably be 
minimal enough to be worth the extra gain in bug-catching. But 
programmers need to understand how the containers they're using 
work and what sort of operations make sense when you're iterating 
over them. I don't see how we could reasonably say otherwise.

But I agree that considering all ranges for a container invalid 
just because you removed an element from that container 
regardless of whether that would affect those ranges is 
definitely too extreme.

> Arbitrary container modification and iteration simply don't mix.

Agreed.

- Jonathan M Davis