Order of evaluation of expressions

I was curious about the order in which some various types of expressions, so I tried this code in the top declaration level, thinking it would fail, but found that it works:

http://play.golang.org/p/CfP3DEC5LP

var x = func() *Foo {
	fmt.Println(f) // prints &{foobar}
	return f
}()

var f = &Foo{"foobar"}

type Foo struct {
	bar string
}

Please note:

• the type Foo struct declaration is at the bottom

• before the type declaration there's a var f declaration and &Foo{] assignment

• before the var declaration, there's a function that's invoked immediately, which references and returns the f variable.

While it didn't surprise me too much that I could make a &Foo{} value even though it took place before the type Foo struct declaration, it did surprise me that I could successfully reference and print the f value before its assignment.

Is this a reliable and specified behavior? I couldn't find any reference to such an ordering in the specification, but perhaps I overlooked it.

See the Go programming language reference

> Within a package, package-level variables are initialized, and
> constant values are determined, according to order of reference: if
> the initializer of A depends on B, A will be set after B. Dependency
> analysis does not depend on the actual values of the items being
> initialized, only on their appearance in the source. A depends on B if
> the value of A contains a mention of B, contains a value whose
> initializer mentions B, or mentions a function that mentions B,
> recursively. It is an error if such dependencies form a cycle. If two
> items are not interdependent, they will be initialized in the order
> they appear in the source, possibly in multiple files, as presented to
> the compiler. Since the dependency analysis is done per package, it
> can produce unspecified results if A's initializer calls a function
> defined in another package that refers to B.

Newer version of the specification (Go 1.20 at time of editing):

> Within a package, package-level variable initialization proceeds stepwise, with each step selecting the variable earliest in declaration order which has no dependencies on uninitialized variables.
>
> More precisely, a package-level variable is considered ready for initialization if it is not yet initialized and either has no initialization expression or its initialization expression has no dependencies on uninitialized variables. Initialization proceeds by repeatedly initializing the next package-level variable that is earliest in declaration order and ready for initialization, until there are no variables ready for initialization.
>
> If any variables are still uninitialized when this process ends, those variables are part of one or more initialization cycles, and the program is not valid.

and (same paragraph)

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