OberonCore

К Оберонам не относится. Но, если есть мысли, почему бы их не зафиксировать.

Я никогда не использовал оператор continue. Считаю, что он годится только для умственно отсталых, которым «внезапно» требуется провалиться в конец цикла. Но тут пришлось работать с унаследованным кодом и признать, что continue имеет право на существование. Он может пригодиться для реализации обхода коллекции с фильтрацией элементов.
В идеале надо бы написать что-то типа такого (псевдокод + LINQ)Когда приходится воплощать это вручную и использовать «if» на весь цикл, добавляется лишний уровень вложенности. Это не здорово, особенно, когда тело цикла приличное (не три строки). Здесь и сгодится нелюбимый continue:
Итак, кратко: только в начале цикла, для реализации фильтра.

Я его не использовал вообще НИКОГДА.
Никогда не было нужды.
Dreak еще использовал в начале освоения С++, но вот уже много лет и он мне не нужен.

Не пойму, почему не так?Всегда так делаю и считаю это правильным. Единственный недостаток, которым я всегда пренебрегаю, так это то, что когда условия изначально не было и его нужно добавить, то в отличии от варианта с continue требуется задевать отступами остальные строки, увеличивая изменения в системе контроля версий. Но с точки зрения ясности и ошибкоустойчивости это лучше.

Да Вы сами написали почему. И я об этом же.
Код был чужой, а циклы на десятки строк.

На самом деле foreach способствует появлению break и continue. Проблема в том, что foreach сложно использовать, как цикл while, который часто бывает нужен. То есть, в while в условие просто можно написать, что пока не прошли все элементы или же не нашли нужный элемент, то итерировать. С циклом foreach же так просто не получится. Если нашли нужный элемент, то нужно или бессмысленно идти до конца или же выпрыгивать с помощью break. Поэтому я считаю, что foreach является "родственником" для break, continue и goto и по возможности его нужно не использовать.

foreach и надо использовать только для полной обработки всех элементов контейнера.
Для поиска он не годится.

Согласен.
Там еще другая проблема, что не очень удобно итерировать элементы контейнера для поиска с while, поэтому некоторые используют foreach, break, continue.

Вы писали про уровень вложенности, но с continue он никуда и не девается, а лишь становится менее явными в виде незримого Else.

Тут, скорее, обратные причина и следствие. foreach был сделан таким, потому что есть break. Иначе, можно было бы снабдить цикл дополнительной конструкцией для структурного поиска. Но зачем, если есть более общий break, которым можно выскакивать из вложенных конструкций?

Недавно заменял на

А любопытно бы пример - приведите, пож.

Мне кажется, RETURN из середины функции сродни continue и break. При неуемном использовании затрудняет понимание программы и поправки - логика получается очень хрупкой. По сути, это завуалированный GOTO, и реализован компилятором именно так. Нарушает структурированный принцип - один вход один выход. К сожалению (моему), в КП он есть, и в ББ встречается чаще, чем мне бы хотелось. Вот жду и надеюсь, может, выкинут его - Вирт же вроде выкинул из поздних Оберонов. И в раннем Паскале/72 их не было емнип. И еще даже в турбопаскале для функций писали Func := expr. А в позднем Обероне вроде и синтаксис приятнее стал - какое-то присваивание после END.

Собственно, эта тема - о реализации шаблона "обход коллекции с фильтрацией элементов".
Вот кусок кода отсюда. Раньше, увидев continue, я бы оценил этот кусок, скажем так, весьма скептически. А сейчас могу сказать, что это просто реализация шаблона: фильтрация пустых элементов.

Код:

foreach (var part in parts) {
    if (string.IsNullOrEmpty(part))
        continue;

    if (result.EndsWith("?") || part.StartsWith("?"))
        result = CombineEnsureSingleSeperator(result, part, '?');
    else if (result.EndsWith("#") || part.StartsWith("#"))
        result = CombineEnsureSingleSeperator(result, part, '#');
    else if (inFragment)
        result += part;
    else if (inQuery)
        result = CombineEnsureSingleSeperator(result, part, '&');
    else
        result = CombineEnsureSingleSeperator(result, part, '/');

    if (part.Contains("#")) {
        inQuery = false;
        inFragment = true;
    }
    else if (!inFragment && part.Contains("?")) {
        inQuery = true;
    }
}

Да, каких только шаблонов не напридумывают.

Забавно, что механизм, насколько можно понять, тот же, что и с придумыванием языков программирования.

Эти дятлы столько херни в циклах напридумывали, что другие дятлы решили просто отказаться от циклов, мол, теперь мы будем всё время ползать туда сюда по спискам, каждый раз. Дешевле десять раз пробежать по одному и тому же списку, чем научить двенадцать обезьян писать цикл Дейкстры без хаков и процедуры с одним RETURN. Ну а развитием этой шизофрении стала виртуальная "постоянная" итерация с реальным подковёрным построением цикла с обычными if-ами внутре и т.д. И все друг друга поддерживают и друг другу поддакивают, мол да, так и надо, это же прогресс, это же развитие, и у нас больше нет сложных тупых циклов с break и continue. Вот как здорово мы проблему решили. И функций с выходом из середины нет, теперь у нас всё есть выражение и всегда досчитывается до конца. А ещё у нас нет null и эксепшнов, вместо него мы держим в памяти тысячи пустотелых объектов типа ValueOrNull. Такой вот мир, а главное, его не инопланетяне здесь силой насаждают, это люди всё сами себе придумали, под тёплое мягкое групповое одобрение.

Изрядно сформулировано ))

Думаю, лучше было бы сделать именование как в Perl:


В целом, в Perl использование next вначале цикла является идиомой:


Но нужно еще попробовать в Обероне привести несколько примеров с использованием или без булевых переменных, для сравнения. Возможно, и не нужно будет добавлять оператор next.

Вот чего точно не нужно добавлять в Оберон.

вообще-то намного лучше добавить Parnas' generalised iterators. но я вот красивого синтаксиса для них придумать не могу. ;-)

p.s.: лучшее, что я смог сочинить:

и, конечно, тот `LOOP`, что есть — аннигилировать.