Здравствуйте, MTD, Вы писали:

ARK>>Непонятно. Это все не нужно. GetIter не должен завершаться с ошибкой.
MTD>Это почему? А если память, например, не удалось выделить?

Если память не удалось выделить, то это крах программы, исключения тут не помогут.

ARK>>HasNext и Next должны быть одним методом MoveNext
MTD>На практике это неудобно, например, я не хочу сдвигать итератор, просто хочу проверить, что есть куда сдвигать.

Ну пусть будет, мне не жалко. Только не надо его тогда в пример приводить для придания многословности (или, если уж приводить, то в обоих примерах).

ARK>>для которого тоже нет резона возвращать ошибку.
MTD>А MoveNext невалидному итератору? Ты уверен, что стоит так замаскировать баг?

Да, согласен, маскировать в данном случае нехорошо. Если брать обычные коды ошибок, то проверку следует сделать один раз после цикла:

for (Iter i : data)
{
    X x;
    if (i.Get(x))
    {
        ...
    }
}
if (data.IteratorCorrupted)
{
    ...
}

Если что-то гипотетическое в духе Раста, то сам цикл должен возвращать некий результат — ошибка или ОК.

Кстати, в С++ с инвалидными итераторами, насколько я понимаю, тоже все "отлично": http://stackoverflow.com/questions/16904454/what-is-iterator-invalidation

Because that error right there? No compiler error, no warning, you lose. You just have to be trained well enough to watch for them and prevent them. Very insidious bugs if you don't know what you're doing. One of the design philosophies of C++ is speed over safety. The runtime check that would lead iterator invalidation to an exception instead of unspecified behavior is too expensive, in the view of C++ language designers.