[1718627440]

I mean plain iteration uses function calls. Iterators are a more advanced concept that needs wrapper objects and function calls.

> as this is often the sign of a bug.

Why? I've just written that yesterday, I had never a problem with that. For example after deleting an element from an array I need to commit this change, by adjusting the size, etc. Why is it so unexpected that I also need to adjust the index? The index needs to be modified anyway.

Where is the notion coming from that this is less preferable than the workarounds, like marking some elements for deletion and then iterating a second time or by making a second container and moving everything that shouldn't be deleted (.filter) ?

[afdbcreid]

Exactly. You need to adjust the index, and if you don't you have a bug. But how to adjust the index depends on what you're doing.

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

[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.

[1718627440]

s/I mean plain iteration uses function calls/I mean plain iteration uses indices/