spec: document that recursive type declarations through type parameters are not permitted

[benjaminjkraft]

Here's a type:

type Rec[type T Rec[T]] interface{ r(T) }

Currently go2go complains with confusing errors; the first declaration fails with Rec is not a generic type (it obviously is) and the equivalent type Rec[type T Rec] interface{ r(T) } fails with Rec is not an interface (it also obviously is).

I assume this shouldn't be allowed: to know if Rec[T] is a valid type for T to implement, we need to know if T implements Rec[T], which is circular. But I can't find anything in the draft design that would prohibit it.

(playground for convenience)

[ianlancetaylor]

I don't think these cases should be permitted but it does seem that the errors generated by the type checker are not ideal.

[griesemer]

We currently report a cycle error here which seems reasonable, but we should review if such code should actually be permitted.

[benjaminjkraft]

The error seems very reasonable to me, but it would be good to have the spec explicitly say what's disallowed (or maybe I just couldn't find it). I would assume something like "a type constraint in the definition of a type T may refer to T", parallel to "An interface type T may not embed any type element that is, contains, or embeds T, recursively." (but a bit broader, to ban e.g. type Rec[T []Rec[T]] ...).

[griesemer]

The type checker now reports

    testdata/manual.go:10:6: illegal cycle in declaration of Rec
                testdata/manual.go:10:6: Rec refers to
                testdata/manual.go:10:6: Rec

which seems pretty decent. We still need to document restrictions in the spec, though. Changed title accordingly.