Problem statement

The current rules for the goto statement state:

Executing the goto statement must not cause any variables to come into scope that were not already in scope at the point of the goto.

In short, a goto statement is not allowed to jump across variable declarations (jumping across nested scopes that declare variables is ok). The underlying reason for that rule is that such variable declarations will not be executed when the goto is taken and thus the respective variables may be in an undefined state (not initialized, not heap-allocated, etc.) at the target label.

This is unfortunate because many times when a goto is used at all, we don't actually care about the values of such variables. A perhaps typical example is the use of goto to factor out error handling to the end of a function:

func f() {
    ...
    if !cond1 {
        goto Error
    }
    if !cond2 {
        goto Error
    }
    ... code here cannot declare new variables even if they are only used locally ...
    if !cond3 {
        goto Error
    }
    ...
    return

Error:
    // handle error
}

Other common scenarios are uses of goto's for early exit where there is no error handling but some finishing up code (e.g., look for goto done, goto out, goto skipped, etc. in the std library).

If the code above needs to use a new variable in the code following the goto and before the Error label, that variable cannot conveniently be introduced close to where it is used, but instead will need to be declared before the goto. Often this also means that one cannot use a short variable declaration because the program state is not what is needs to be for an initialization expression.

In summary, using a goto sometimes requires that otherwise unaffected code will need to move variable declarations before the use of the goto since the goto would not be permitted otherwise. This is at best annoying, and at worst may lead to less readable and maintainable code due to bulk variable declarations, without initialization expressions, sometimes much before they are actually needed.

Observation

Obviously, if code accesses a variable at a target label of a goto, that variable must be declared before the goto as otherwise its value may be unknown. But the values of variables that are not accessed at the target label don't matter exactly because the code doesn't use those values.

This observation leads directly to the proposal.

Proposal

We propose to remove the goto restrictions on variable declarations in favor of a new rule for variable accesses (edited per discussion):

A variable that would normally (without the presence of any goto) be in scope at a label declaration is not in scope if there is a goto to that label which jumps over the variable's declaration.

It is an error to access a variable (lexically) after a label declaration if there is a goto to that label which jumps over the variable's declaration.

Examples

The code fragment:

func _() {
	goto L
	x := initexpr
	use(x)
L:
}

currently is invalid and leads to the compiler error:

x.go:4:7: goto L jumps over declaration of x at x.go:5:6

To make it valid, we would need to write something like:

func _() {
	var x T // declare x here because of goto below
	goto L
	x = initexpr
	use(x)
L:
}

With the proposed new rule, the goto error will disappear, making the original code fragment valid. On the other hand, if the code were to make use of x at the label L as well:

func _() {
	goto L
	x := initexpr
	use(x)
L:
	use(x)
}

the compiler might report instead (edited per discussion):

x.go:4:6: cannot access x (goto L jumps over declaration of x at x.go:5:6)

The error reported currently with the goto statement could be used literally as explanation in the error reporting the invalid variable access at the target label.

It is important that the variable remains in scope to make it impossible that another variable with the same name is declared in what used to be the variable's scope if there was no goto. For instance, the following code remains invalid with this proposal:

func _() {
	goto L
	var x T
	use(x)
L:
	// per the proposal, x is inaccessible here, yet it remains in scope
	var x T // <<< ERROR cannot declare another x in the same scope
}

Implementation

The implementation is expected to be straight-forward: The new rule shifts an existing error, reported with a goto, to a specific access of the variable which caused the goto error. More detailed:

Whenever the compiler's analysis detects that a goto jumps over a variable declaration, instead of reporting that as an error, the compiler remembers that variable as inaccessible at the target label. At the target label, all such inaccessible variables are removed from scope. This will in turn make it impossible to access such a variable in the code. (A more user-friendly implementation might keep the variable in scope but upon access would also check if it was marked inaccessible. Such an approach could provide a better error message). If the variable is accessed lexically after the target label, the compiler reports an error.

Alternatives

#26058 proposes an alternative approach to achieve a similar outcome: Instead of disallowing variable access if a goto jumped over the variable's declaration, #26058 disallows a goto if it jumps over a variable declaration of a variable that is used after the target label. In other words, #26058 makes the existing restriction on goto's slightly less onerous while this proposal removes that restriction altogether but introduces a new one for variables.

Summary

This proposal removes a restriction on uses of goto's in favor of a new rule for variables: Instead of making it invalid for a goto to jump over a variable declaration, it will become invalid to access a variable (after a label) whose declaration was jumped over. This is an improvement over the existing situation because the current rules always disallow variable declarations that are being jumped over, while the new rules only lead to an error if such variables are used at the target label, which is a less common scenario.

Because the proposal removes an existing restriction, this is a backward-compatible language change.

#26058 achieves a similar outcome through a slightly different approach. It does not seem obviously clear which approach is better.