Why does Go have a “goto” statement

Question

I was surprised to find that Go has a \'goto\' statement. I\'ve always been taught that \'goto\' statements are a thing of the past and evil for it occludes the actual flow

Answer 1

When we actually check the source code of the Go standard library, we can see where gotos are actually well applied.

For example, in the math/gamma.go file, the goto statement is used:

  for x < 0 {
    if x > -1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }
  for x < 2 {
    if x < 1e-09 {
      goto small
    }
    z = z / x
    x = x + 1
  }

  if x == 2 {
    return z
  }

  x = x - 2
  p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6]
  q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7]
  return z * p / q

small:
  if x == 0 {
    return Inf(1)
  }
  return z / ((1 + Euler*x) * x)
}

The goto in this case saves us from introducing another (boolean) variable used just for control-flow, checked for at the end. In this case, the goto statement makes the code actually better to read and easier follow (quite in contrary to the argument against goto you mentioned).

Also note, that the goto statement has a very specific use-case. The language specification on goto states that it may not jump over variables coming into scope (being declared), and it may not jump into other (code-)blocks.

Answer 2

Goto statements has received a lot of discredit since the era of Spaghetti code in the 60s and 70s. Back then there was very poor to none software development methodology. However Goto are not natively evil but can of course be misused and abused by lazy or unskilled programmers. Many problems with abused Gotos can be solved with development processes such as team code reviews.

goto are jumps in the same technical manner as continue, break and return. One could argue that these are statements are evil in the same manner but they are not.

Why the Go team has included Gotos are probably because of the fact that it is a common flow control primitive. Additionally they hopefully concluded that the scope of Go excludes making an idiot-safe language not possible to abuse.

Answer 3

Goto is a good idea when none of the built-in control features do quite what you want, and when you can express what you want with a goto. (It's a shame in these cases in some languages when you don't have a goto. You end up abusing some control feature, using boolean flags, or using other solutions worse than goto.)

If some other control feature (used in a reasonably obvious way) can do what you want, you should use it in preference to goto. If not, be bold and use goto!

Finally it's worth noting that Go's goto has some restrictions designed to avoid some obscure bugs. See these restrictions in the spec.