The current initialization rules disallow this: It's not about how x is used, it's the fact that it is used in the initialization of itself.

(go/types also disallows this.)

p.s. if I do:

var x T = T{p: &x}

Then it typechecks, but then dies with:

tmp1.go:7: initialization loop:

So why can't I use the address of x to initialize x? It seems the & should break the loop somehow.

Same thing: it's an initialization loop per the spec rules.

We could change the rules I guess, but it general, taking the address of a variable being initialized and using that address during initialization doesn't guarantee that we don't indirect that address and then use the variable during initialization.

Per the spec: "Dependency analysis does not rely on the actual values of the variables, only on lexical references to them in the source, analyzed transitively." (https://golang.org/ref/spec#Package_initialization)

Agreed that it seems to be an initialization loop, so it's not allowed by the spec currently.

FWIW, it does seem like a bug though that we fail to typecheck "var x = T{&x}" the same as "var x T = T{&x}", but since it's an initialization loop anyway, I'm not sure it's worth fixing that corner case.

PS: I guess we could change the spec as it would be a backward-compatible change. But it wouldn't catch e.g. the following error anymore:

var x T = f(&x) // & breaks the cycle
func f(p *T) T { return *p }

Yes, I guess that makes sense. I'll have to figure out some other way to get those pointers initialized. Maybe some init functions to patch up those links later.

https://play.golang.org/p/fvNEJWTH8c
:-)

I've always wanted to make my code depend on linker layout order...