Is there any real use for break in a select / case statement?

[Dean Schulze]

The break keyword terminates execution of a select statement, but is there any real use for break in a select / case statement?

The select statement executes one of its cases that can proceed or the optional default statement and then program execution continues after the select {...} block.  Since the select statement will complete after a case or default completes what reason is there to use break  in a case or default?  I can't think of one.

Using break in a select / case statement seems pointless.

[Jan Mercl]

On Sat, Sep 20, 2025 at 12:05 PM Dean Schulze <dean.w....@gmail.com> wrote:

> The break keyword terminates execution of a select statement, but is there any real use for break in a select / case statement?

For example:

loop:

        for ... {

                switch ... {

                case foo:

                        ...

                case bar:

                        break loop

                }

        }

[Dan Kortschak]

Also, it means that you can avoid an else block, instead breaking at
the end of the true block of an it statement

select {
case v <- c:
if trueCase(v) {
do stuff.
break
}
// false case
do other stuff.
...
}

[Dean Schulze]

I was asking about select.

[Dean Schulze]

I don't think it was included in the language spec to be a substitute for an else in a case statement.

[Matthew Zimmerman]

It does allow you to avoid a fallthrough at the end of the case.

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/e8d9bd75-44fe-4280-a550-772efc6c32fbn%40googlegroups.com.

[Dean Schulze]

There is no fallthrough in a select.  You can use fallthrough in a switch case statement to execute the next case but you wouldn't use both fallthrough and break together.

[Jan Mercl]

On Sat, Sep 20, 2025 at 2:11 PM Dean Schulze <dean.w....@gmail.com> wrote:

> I was asking about select.

No difference: https://play.golang.com/p/35rcyiWozwn

[Ian Lance Taylor]

My recollection is that we discussed how to handle an unlabeled break statement in a select statement. Should it break out of the select or should it break out of the enclosing loop? We wanted break in a switch to break out of the switch, not the loop, to be less confusing to C programmers. And select and switch look pretty similar on the page. Handling break the same way for both seemed to make the most sense.

Ian

[Stephen Illingworth]

On Saturday, 20 September 2025 at 16:43:39 UTC+1 Ian Lance Taylor wrote:

My recollection is that we discussed how to handle an unlabeled break statement in a select statement. Should it break out of the select or should it break out of the enclosing loop? We wanted break in a switch to break out of the switch, not the loop, to be less confusing to C programmers. And select and switch look pretty similar on the page. Handling break the same way for both seemed to make the most sense.

It would be nice if break and continue could have an optional "argument" to indicate what to break out of. For example, to break out of a loop inside a switch block you could write "break loop". It would be an implicit label on the nearest loop.

I feel this might be common enough to be useful but I can't prove that. At the moment I wouldn't bother with labelling at all and I'm more likely to put the loop inside an anonymous function and return from within the switch.

[Ian Lance Taylor]

Unless I misunderstand, Go already has that feature. 

Ian

[Stephen Illingworth]

I'm suggesting that there might be a way of implicitly labeling the nearest loop. For example:

for {
switch rand.IntN(3) {
case 0:
case 1:
break for
case 2:
}
}

At the moment, you have to explicitly define the label:

func main() {

myloop:

for {
switch rand.IntN(3) {
case 0:
case 1:
break myloop
case 2:
}
}

}

This works and there's nothing wrong with it, but maybe there's a case for the implicit form too.

I recognise that there are yet other ways of dealing with the problem, but the 'implicit label' seems like a neat solution to me.

[Dan Kortschak]

On Sat, 2025-09-20 at 05:11 -0700, Dean Schulze wrote:
> I don't think it was included in the language spec to be a substitute
> for an else in a case statement.

That wasn't the question. You asked if there is a use. That is a use,
and one that allows leftwards code which is conventional in Go.

[Ian Lance Taylor]

On Sat, Sep 20, 2025, 11:41 AM Stephen Illingworth <stephen.i...@gmail.com> wrote:

I'm suggesting that there might be a way of implicitly labeling the nearest loop. For example:

for {
switch rand.IntN(3) {
case 0:
case 1:
break for
case 2:
}
}

At the moment, you have to explicitly define the label:

func main() {

myloop:

for {
switch rand.IntN(3) {
case 0:
case 1:
break myloop
case 2:
}
}

}

This works and there's nothing wrong with it, but maybe there's a case for the implicit form too.

I recognise that there are yet other ways of dealing with the problem, but the 'implicit label' seems like a neat solution to me.

Apologies for misunderstanding. 

Since the most common case for a labeled break is nested for loops, personally I don't think the benefit here is worth the language complication. 

Ian

[Dean Schulze]

That makes sense.  Thanks for the explanation.

[Dean Schulze]

That's a use for it, but I think it would be cleaner to use a local variable to exit the for loop

On Saturday, September 20, 2025 at 4:26:27 AM UTC-6 Jan Mercl wrote: