fallthrough for select

[Yongjian Xu]

In Go, select and switch statements are similar just that select is specific for channel multiplex operations. The fallthrough statement is defined to flow the control to the next case statement, upon reading the lang spec, it does not seem that specific to the "switch" statement, but yet for some reason, it is only defined for switch.

Anyway, maybe someone could enlighten me a bit as of why we have chosen not to support fallthrough in select. And just for my greedy heart, can we add it to select...

[Dan Kortschak]

The expectation of the type is different for each block.

[Benjamin Measures]

Note the fallthrough statement is also disallowed for type switches, as this would be dangerous.

Falling through select declarations, assignments or communications would either be dangerous (in the case of declarations) or have indeterminate side effects (in the case of whether or not an assignment or communication happened).

[Dan Kortschak]

On Fri, 2015-01-23 at 09:59 +1030, Dan Kortschak wrote:
> The expectation of the type is different for each block.
>

Right answer for the wrong question - Benjamin's is your answer.

[Yongjian Xu]

but fallthrough is explicitly spelled out and the semantics is clearly defined in the language, any side effects would be by design isnt it? In other word, the programmer who wrote that has explicitly allowed such effect to happen, compare to C's implicit fallthrough.

On Thu, Jan 22, 2015, 16:21 Benjamin Measures <saint....@gmail.com> wrote:

Note the fallthrough statement is also disallowed for type switches, as this would be dangerous.

Falling through select declarations, assignments or communications would either be dangerous (in the case of declarations) or have indeterminate side effects (in the case of whether or not an assignment or communication happened).

--
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.

[Andrew Gerrand]

C doesn't have select, so its semantics are irrelevant here.

Select statements choose between available channel operations. Falling through from one select case to another doesn't make sense.

Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Yongjian Xu]

I thought about this a bit more and I think you probably right. Originally, I found myself writing code to handle situations like to provide the same function to a number of cases, eg when timed out, when a certain notification sent, when a ctx done, I would have to write the same function 3 times, so I thought why couldn't we allow fallthrough so that I only need to express one time for all of them. But channel conditions are different, fallthrough could result undesired behavior changes.

Anyway, thanks.

[Michael Jones]

You are free to have a select that records which choice happened, followed by a switch that let's cases share choice handlers.

[sim.ch...@gmail.com]

Hi, I know this is kind of old and I'm not sure anyone will answer, but even after the previous discussion I feel like any kind of switch-like statements should be able to fallthrough.

The answer that it doesn't make sense because you're supposed to choose between different available channel operations is not really a good point because you could say the same thing for the switch statement.

The switch statement is supposed to choose from a set of unique values, so it doesn't make sense to fallthrough another value?

My point is that the fallthrough operation allows us to define common code for different cases, which could be really useful in any switch-like statements.

[Jan Mercl]

On Sun, May 6, 2018 at 6:34 AM <sim.ch...@gmail.com> wrote:

> ... I feel like any kind of switch-like statements should be able to fallthrough.

        switch x := f.(type) {

        case *Foo:

                ...

                falthrough

        case *Bar:

                x.Baz() // <- What type is 'x' here?

        }

--

-j

[matthe...@gmail.com]

The proposal I opened for this was declined recently: https://github.com/golang/go/issues/23196

Matt