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
