[lubutu]

And yet backward goto is extremely useful. Consider this Java,

  redo: while(true) {
      for(Item x : xs)
          if(f(x))
              continue redo;
      break;
  }

With goto,

  redo:
  for(Item x : xs)
      if(f(x))
          goto redo;

Most people seem at first to balk at the goto, even though they're functionally identical, and the goto is much clearer and less error prone...

[glassx]

The article mentions that as well: "Backward gotos could be ok when it makes sense that your error case would repeat the last iteration"

Btw, in Ruby there are two keywords that are basically backward gotos: redo and retry.

[einhverfr]

That's the exact case where I saw it in the PostgreSQL code. Re-doing join pruning when a join was eliminated.

[ajanuary]

while (xs.Any(x => f(x))) { }

Pulling things out into other functions makes it even clearer.

Though yes, the goto is clearer than the labelled continue. I wouldn't necessarily agree that it's less error prone though.

[lubutu]

Well, if we permit functional programming languages all the problems concerning imperative control flow magically go away...

[ajanuary]

I just used higher order functions to keep the example short, and I'd use them irl to avoid code repetition. The concept still applies without them:

    while (fTrueForAny(xs)) { }

    boolean fTrueForAny(List xs) {
      for (Item x : xs) {
        if (f(x)) {
          return true;
        }
      }

      return false;
    }

There isn't anything non-imperative about higher order functions.

    var externalDataStore = new ExternalDataStore()
    [1, 2, 3, 4].each(x => externalDataStore.store(x))
    externalDataStore.getItems().each(item => print(item))

Plenty of higher order functions, and plenty of non-functional, ordered, stateful, imperative code.