FAQ
I dislike how "break" is treated inside switches in Go.

Because Go did a good job at eliminating switch fall-through, one shouldn't
need the keyword break outside loops. So I'm confused that it still sees
use inside switches. I would think that more often than not, you want to
exit a loop based on a result you found inside the switch, rather than exit
the switch altogether.

The wiki <https://github.com/golang/go/wiki/Switch> gives this example:

command := ReadCommand()
argv := strings.Fields(command)
switch argv[0] {
case "echo":
     fmt.Print(argv[1:]...)
case "cat":
     if len(argv) <= 1 {
         fmt.Println("Usage: cat <filename>")
         break
     }
     PrintFile(argv[1])
default:
     fmt.Println("Unknown command; try 'echo' or 'cat'")
}

But why can we not do a simple if-else?

case "cat":
     if len(argv) <= 1 {
         fmt.Println("Usage: cat <filename>")
     } else {
         PrintFile(argv[1])
     }

I'll admit that such conflicts can be solved with labelled break and continue or (heaven forbid) goto. But I don't think such significant features should be necessary in this case. I'd also like to point out that it's inconsistent with "continue". A "continue" inside a switch inside a loop goes to the next iteration of the loop, but a "break" inside a switch inside a loop leaves the switch and does not interrupt execution of the loop. I think that "break" should stop the loop instead, because any control within the switch it offers can be accomplished by other control structures.

I'll also admit that I might have ignored a use case for breaks inside switch. If that's the case, perhaps a new keyword could be created, such as "stop" or "quit", to exit out of a switch, so that it consistently exits switches and "break" consistently exits loops?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nigel Tao at Mar 24, 2016 at 11:02 am

    On Thu, Mar 24, 2016 at 3:41 PM, Linus Drumbler wrote:
    I think that "break" should stop the loop instead, because any control
    within the switch it offers can be accomplished by other control structures.
    You do have a valid point, but it's pretty much academic at this
    point. We can't break (haha) existing programs during the Go 1.x
    releases due to https://golang.org/doc/go1compat, and I wouldn't
    expect a Go 2.0 any time soon.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Klaus Post at Mar 24, 2016 at 11:35 am

    On Thursday, 24 March 2016 08:41:55 UTC+1, Linus Drumbler wrote:
    I dislike how "break" is treated inside switches in Go.
      The reason I think it is a worthwhile addition is that it reduces
    "indentation" level. In your "if-else" you quickly run into cases where
    you have 5 nested ifs, if you have no way of getting out of the "case".
    With "break", you can do what you want and "return" early. That way you
    don't stack up your ifs, making the code easier to read, similar to how Go
    promotes "return early on errors".

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jesse McNelis at Mar 24, 2016 at 12:05 pm

    On 24 Mar 2016 6:41 p.m., "Linus Drumbler" wrote:
    I dislike how "break" is treated inside switches in Go.
    I believe the stated reason it's like that is just to be similar to other c
    like languages so as to avoid the confusion and difficult to find bugs that
    would result from it being different.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 24, '16 at 7:41a
activeMar 24, '16 at 12:05p
posts4
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase