spec: no rule about loops in constant definition

[momchil-velikov]

The compiler issues error constant definition loop for the following program:

package main
import "fmt"
const C = len(u)
func f() ([1]int, [C]float64) {
    return [...]int{1}, [...]float64{1.1}
}
var u, v = f()
func main() {
    fmt.Println(C, v)
}

In fact the value if C (resp. the type of u) does not depend on the type of the second return of f.

The same program is compiled successfully by gccgo.

PS. Another test case

package main
import "fmt"
const C = len(u)
type S struct {
    X [1]int
    Y [C]int
}
var s S
var u, v = s.X, s.Y
func main() {
    fmt.Println(C, v)
}

[cznic]

I believe this is working as intended.

From the specs: Package initialization:

Dependency analysis does not rely on the actual values of the variables, only on lexical references to them in the source, analyzed transitively. For instance, if a variable x's initialization expression refers to a function whose body refers to variable y then x depends on y. Specifically:

• A reference to a variable or function is an identifier denoting that variable or function.
• A reference to a method m is a method value or method expression of the form t.m, where the (static) type of t is not an interface type, and the method m is in the method set of t. It is immaterial whether the resulting function value t.m is invoked.
• A variable, function, or method x depends on a variable y if x's initialization expression or body (for functions and methods) contains a reference to y or to a function or method that depends on y.

According to the above, C depends on u, u depends on f and f depends on C, which completes the circular dependency.

[bradfitz]

There is some bug somewhere if gc and gccgo disagree.

/cc @alandonovan @griesemer @ianlancetaylor

[alandonovan]

I agree with cznic that this is a dependency cycle, so all three frontends should report it as such. Thus this is a bug report against gccgo.

FWIW, go/types also yields an error, but the wrong one:

a.go:6:25: cannot return ([...]float64 literal) (value of type [1]float64) as value of type [0]float64

[mdempsky]

Note that C is a constant, not a variable, so strictly speaking there cannot be a variable initialization/dependency cycle between C and u. Is there some other part of the spec that disallows @momchil-velikov's program(s)?

[alandonovan]

Good point; the broader problem is that the spec does not currently forbid this program:

const (
    x = y
    y = x
)

[ianlancetaylor]

I've changed this to be a bug report against the spec.

[momchil-velikov]

@alandonovan, I don't think there is a dependency cycle, unless a somewhat conservative notion of dependency is introduced in the spec, according to which the type of u would depend on the type of f as a whole, as opposed to depending only on the type of the first return of f.

[alandonovan]

@momchil-velikov: I was mistakenly reading the specification of variable initialization cycles, which treats a reference to a function as a reference to all the entities mentioned in the function body. You are right that the corresponding text for constants need not be so conservative, but currently there is no such text at all.

[mdempsky]

I think @alandonovan's sample

const (
    x = y
    y = x
)

is obviously invalid and should be disallowed, because it's a cycle in constant declarations.

However, I think @momchil-velikov's original sample is still interesting, because it reveals that current Go type checkers are unnecessarily integrating type propagation/inference with constant evaluations. If those two steps are split into separate phases, the cycle goes away.

Original:

const C = len(u)
func f() ([1]int, [C]float64) { ... }
var u, v = f()

Apply type propagation/inference:

const C int = len(u)
func f() ([1]int, [C]float64) { ... }
var (u [1]int, v [C]float64) = f()

Apply constant evaluation (including evaluating array bounds, which I expect in practice would even include evaluating the constant literal 1 in [1]int):

const C int = 1
func () ([1]int, [1]float64) { ... }
var (u [1]int, v [1]float64) = f()

Am I overlooking any counter examples where separating these steps would fail? I.e., programs where assigning types to names/expressions requires constant evaluation?

[ianlancetaylor]

Our goal should be to write the simplest possible rule, not the rule that permits the largest number of programs. That is the rule we've tried to follow for initialization loops in general. The simpler the rule, the more likely that all Go compilers will agree on the definition of a valid program.

[griesemer]

@mdempsky I believe it is difficult to separate type inference from constant evaluations - they are necessarily coupled: the length of an array type can be any constant expression, that value of which becomes part of that type. And a constant expression may depend on the result of a compile-time evaluated call of len(x), where the result of len(x) depends on the type of x.

I agree that some type checkers (gc, go/types, even) use a somewhat ad-hoc approach at the moment to resolve cycles - in the sense that we don't necessarily have proof that we caught all cases correctly. Determining explicit dependencies first, and evaluating types (and constants) afterwards, in a controlled manner, might be the way to go.

The spec doesn't say much if anything about cycles in constant expressions.

For what it's worth, I don't think this is for 1.7. These are esoteric corner cases, and hardly showstoppers.