all: switch fallthrough bug. Variables scoped outside of switch remain unchanged when modified inside a case block.

[dexterp]

When a case statement modifies a variable that is scoped outside a switch statement, the next fallthrough + case statement evaluates the variable as unchanged for the line where the next case is set, but is evaluates as changed within the next case code block. See example code in "What did you do?

What version of Go are you using (go version)?

$ go version
go version go1.20.4 darwin/arm64

Does this issue reproduce with the latest release?

Yes, at the time of writing 1.20.4

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOOS="darwin"
GOARCH="arm64"

What did you do?

func main() {
	F()
}

func F() error {
	var err error
	switch {
	case true:
		fmt.Println("first case statement should execute")
		err = FuncNoError()
		fallthrough
	case err == nil:
		fmt.Println("second case statement should execute")

		// FUNCTION RETURNS AN ERROR
		err = FuncHasError()
		fallthrough
	case err == nil:
		fmt.Println("third case statement SHOULD NOT execute")
		err = FuncNoError()
		fallthrough
	case err != nil:
		fmt.Printf("type of err: %T\n", err)
		return fmt.Errorf("found an error: %w", err)
	}
	return nil
}

// FuncNoError a function that returns no error
func FuncNoError() error {
	return nil
}

// FuncHasError a function that returns an error
func FuncHasError() error {
	return errors.New("FuncHasError")
}

What did you expect to see?

• The third case statement case err == nil should evaluate as false skipping the code block.
• The fourth case statement case err != nil even though err is nil (according to fmt.Printf("%T", err)) the fourth code block is still executed. So err is remains "nil" when evaluated at the same line as the case statement, but evaluates to not nil when in the case code block.

The output from the code above should be

first case statement should execute
second case statement should execute

What did you see instead?

first case statement should execute
second case statement should execute
third case statement SHOULD NOT execute
type of err: <nil>

[Jorropo]

@dexterp The spec says:

A "fallthrough" statement transfers control to the first statement of the next case clause in an expression "switch" statement. It may be used only as the final non-empty statement in such a clause.

Looks to me like this behaviour is correct, it doesn't mention doing any checks, it goes to the next block.

Changing this would require to change the language, if anything I would suggest putting the behaviour you are asking for on the continue keyword because as-is fallthrough is usefull and it just sounds like it make sense (in switchs continue, continue checking) this would be a breaking change and be put in the Go2 maybe go.mod go 1.xx pile. 🙂

Also maybe clarifying the current behaviour in the spec ?

---

I think it makes more sense when you think about it from the C point of view. cases are like conditional labels or literal matched labels.
Once you started executed code in the switch body the cases don't exists anymore everything is one more or less linear piece of code that happen to have labels in it. (because the fallthrough is implicit there)

---

In your example I would use an IIFE:

func F() error {
	if err := func() error {
		fmt.Println("first case statement should execute")
		if err := FuncNoError(); err != nil {
			return err
		}

		fmt.Println("second case statement should execute")

		// FUNCTION RETURNS AN ERROR
		if err := FuncHasError(); err != nil {
			return err
		}

		fmt.Println("third case statement SHOULD NOT execute")
		if err := FuncNoError(); err != nil {
			return err
		}
		return nil
	}(); err != nil {
		fmt.Printf("type of err: %T\n", err)
		return fmt.Errorf("found an error: %w", err)
	}
	return nil
}

[seankhliao]

working as intended.

[dexterp]

I will withdraw. I've only ever used fallthrough with Go and I misinterpreted the docs.

[xmo-odoo]

Changing this would require to change the language, if anything I would suggest putting the behaviour you are asking for on the continue keyword because as-is fallthrough is usefull and it just sounds like it make sense (in switchs continue, continue checking) this would be a breaking change and be put in the Go2 maybe go.mod go 1.xx pile. 🙂

FWIW this was proposed (and rejected) in #13935. Though it was hanging off of labelled continue and the switch being labelled, I don't think the primary objections have changed.

[Jorropo]

Having continue with implicit label not get caught on switches even tho you can continue them (but only with labels) is a way to solve the language compatibility issue but I find that extremely confusing.
Thx for linking #13935.