[1718627440]

But I need to adjust indices for a container when modifying anyways, regardless whether it occurs in a loop. It's not different than doing not doing it in the loop. Also I'm also modifying the loop index anyways, since I want to iterate, not always touch the same object.

> And sometimes it's a simple bug where you never meant to modify the collection.

How do you accidentally modify an array, which would be different from any other variable?

[afdbcreid]

But the index is not yours. The iterator keeps it.

> How do you accidentally modify an array, which would be different from any other variable?

Like you cause any other simple bug. When there are tons of things and it's not a simple variable. Or even just a typo. That also happens.

[1718627440]

If the iterator abstracts the iteration away, it should also abstract over the modification.

> Like you cause any other simple bug.

Yes, but we don't forbid modifying other things, just because you could modify them by accident, because you want to modify them some of the time. Why does a[i] = ... needs to be prevented, but a = ... is fine?

[afdbcreid]

> If the iterator abstracts the iteration away, it should also abstract over the modification.

That's no longer a simple iterator; it's a collection wrapper that represents in-iteration collection. It can be useful, and it is possible to write! But I don't think this is what programming languages should offer as their default iterator. Also, how do you solve the problem of mutation done through the collection without involving the iterator?

> Yes, but we don't forbid modifying other things, just because you could modify them by accident, because you want to modify them some of the time. Why does a[i] = ... needs to be prevented, but a = ... is fine?

I agree, this is not a strong reason on its own, but it strengthen the main reason.

[1718627440]

> That's no longer a simple iterator; it's a collection wrapper that represents in-iteration collection.

I am not using a language with iterators in daily work, but that doesn't sound like a real problem to me. The iterator is already provided by the container type and the container already supports removing things:

    iter<T>::drop_current () {
        this->container.remove_at (this->index);
        this->index--;
    }

> Also, how do you solve the problem of mutation done through the collection without involving the iterator

Same like you solve mutation done to the container while the iterator exists, when the iterator doesn't allow mutating. That problem already exists.

I fail to see how mutating a container while iterating is more likely to be a bug, than mutating any other thing.