<pre class="notranslate">At the package-level, all (non-imported) identifiers are immediately in package scope
which permits self-referential declarations.

This is important for type declarations; e.g.:

type List struct{
   elem int
   next *List
}

a) For type declarations, certain recursive constructs would lead to
"infinitely" sized types and are obviously impossible and invalid; e.g.:

type T [n]T
type S struct{field S}
type I interface{I}

The spec should specify the exact rules for these (straight-forward) cases.

b) There are pathological cases of self-referential declarations, typically involving
constant expressions referring used as length value of array declarations, whith the
constant expressopns referring to the yet-to-be declared variable/type. E.g.:

<a href="http://play.golang.org/p/h9KlMctIqD" rel="nofollow">http://play.golang.org/p/h9KlMctIqD</a>
<a href="http://play.golang.org/p/Ybsig_M8oF" rel="nofollow">http://play.golang.org/p/Ybsig_M8oF</a>
<a href="http://play.golang.org/p/akqH5uMoOD" rel="nofollow">http://play.golang.org/p/akqH5uMoOD</a>
etc.

(see also <a href="https://golang.org/issue/7525" rel="nofollow">issue #7525</a>).

It would be nice if we specify if/how these cases are valid/invalid, or perhaps exclude
them more categorically. While these are all pathological cases, a clear rule would
inform how much effort needs to go into a language implementation/compiler. At this
point, all three front-ends (gc, gccgo. go/types) tend to do different things.</pre>
<pre class="notranslate">The spec says "An interface type T may not embed itself or any interface type that
embeds T, recursively.", but nothing like this is mentioned for structs.

(A struct containing itself would obviously need infty memory, but the spec should
probably still explicitly mention that these are illegal while a struct containing a
pointer to itself is fine</pre>